torusle

Might want to share your harness /s

Many programs written in assembly language used self modifying code back then. It saved RAM and improved performance. All programs that used such trickery would have broken by a binary translator.

So sad.

Most American post I have seen here since ages.

However!

As soon as you cabled all together their imperfections added up and they started to groove like nothing that has been heard before.

They knew: If Linux makes it in Munich, it will likely spread over and they loose tons of contracts with other German states.

Aren't Quadtrees covered by almost all basic data-structure books? It is the most simple form of taking the binary tree into the next (2D) dimension.

For those who don't know: Vias are not only used to get an electrical connection from one side of the PCB to another.

You also need them to keep radiation in check and often to move heat away.

With this technique, good luck getting through EMC testing for anything but trivial circuits.

this is really bad. It might be a breakthrough of what you are doing, but when I listen to the output all of the timing and phrasing is aweful.

That was a thing back in the 90th..

I wonder how hard the performance hit from moving values between integer and float pipeline is nowadays.

Last time I looked into that was the Cortex-A8 (first I-Phone area). Doing that kind of trick costed around 26 cycles (back and forth) due to pipeline stalls back then.

> 2. Mobile consumer hardware is sufficiently fast for the application > operations (eg. Cryptographic operations)

You are right here. It is possible to emulate a card using mobile phones. We've been able to shim/emulate any card for much longer.

The thing is: To connect to the payment system you need a certificate. And you simply don't get it unless you can prove that you have all kinds of security measures applied.

For android and apple, the actual payment stuff runs inside a isolated little micro-controller which has been certified and is temper proof/protected. This little thing is fortified so far that it will destruct itself when you try to open it up. There are alarm meshes, light sensors and much more inside the chip to detect any intrusion just to protect the certificate.

If you don't have that security, the payment providers will deny you their certificate, plain and simple.

You can build your own thing using card emulation via apps, but you will take all the risks.

How it works in practice is the following: These temper proof micro-controllers can run java-card code. You can write an applet for them, get it installed (if you have the key from apple/google - not easy). Then install it and you have a two-way communication: Your applet inside the secure world communicating with the payment world, and your ordinary mobile app showing things on the screen.

1st: The message overhead during communication is not an issue. It is tiny compared to the time it takes for the credit card to do it's crypto thing.

2nd: This won't be adapted ever. There is simply way to much working infrastructure out there build on the APDU protocol. And there are so many companies and stakeholders involved that doing any change will take years. If they start aligning on a change, it would be something that makes a difference, not something that safes time in the order of 5 to 20 milliseconds. per payment.