This is actually pretty brilliant... I wonder if the FP registers can actually be traced back to a specific page file or if they would just be logged and shotgunned.

Vya DomusYou do not need a 8192 bit wide register to compute 8192 bit wide calculations , you just need a huge sequence of operations involving smaller registers. And then if you have access to them you can easily infer what those huge numbers are from observing that series of results coming of those registers. Compilers do this all the time when you try , for example to do 64 bit math on 32 bit capable machines. If you look at the machine code generated by it , you can tell where that 64 bit calculation took place even though it involved only 32 bit registers.




Well , that's the whole point of it , you don't need to get the key in it's entirety , you just need to know what was in those registers at the right time.

Well, it's not like you know exactly when those registers have the data you're looking for and that there are only certain times that this becomes a possible exploit but, that's completely beside the point. Once again, it doesn't really matter either way because encryption keys aren't going to be stored in floating point registers because most cryptographic ciphers do integer math and bitwise operations. So there is absolutely no reason why something like an encryption key should be an FP register. It literally makes no sense.

efikkanThe problem here is many people automatically conclude that since there is a leak of information, that information can be sensitive, and then jump to the worst case example of sensitive data, forgetting if that kind of data can be stored there in the first place. And you're right, encryption keys will not be stored in the FPU state register.

People need to understand when floating point is used and it's not for cryptography most of the time. Hell, you don't even want to do financials or anything where numbers have to add up with FP. You use this for things like timing and geometry where being exact isn't a big deal, literally the opposite of cryptography.

AquinusPeople need to understand when floating point is used and it's not for cryptography most of the time. Hell, you don't even want to do financials or anything where numbers have to add up with FP. You use this for things like timing and geometry where being exact isn't a big deal, literally the opposite of cryptography.

Single-precision floating points are 32 bits, or 7 decimal places of precision. Almost all applications use integers or floating points, anything more would be an erroneous allocation of memory. I can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

Modern encryption has a result typically 512 bits, with older encryption ranging from 128-256 bits. These signatures are generated using a number of factors including random seeds, server ticks, timezones, etc., that are typically stored in floating point registers.

BlueberriesI can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

Yes you can. It's called fixed point numbers. $19.00 would be represented as 1900.

Once again - when I searched for a secure laptop to hold sensitive data, it could NOT be Intel. No Intel system should be used to store any sensitive data.

btarunrOne by one, all of the secret-sauce features that made Intel processors faster than AMD are turning out to be exploitable; and being neutered by software patches.

That's just silly. The most recent vulnerabilities like Spectre and Spectre-NG were targeting more general purpose out of order execution you know...

Captain_TomOnce again - when I searched for a secure laptop to hold sensitive data, it could NOT be Intel. No Intel system should be used to store any sensitive data.

Honestly, when I was in a similar boat, it HAD to be intel, only because the ME is more understood than AMD's PSP.

Neither is truly secure. If you worry that much, you are basically going to have to worry. Sorry.

leaked intel road map now includes a "Exploit Lake EP"

AquinusYes you can. It's called fixed point numbers. $19.00 would be represented as 1900.

I suppose you could but I would still hate you for doing it.

BlueberriesI suppose you could but I would still hate you for doing it.

Do you hate your PC?

It does it all the time. Trust me.

I feel sad for my Intel CPU, its freaking full of security holes.

jigar2speedI feel sad for my Intel CPU, its freaking full of security holes.

You should feel praised for it being so Holy. :nutkick:

Blueberries

I suppose you could but I would still hate you for doing it.

You wouldn't hate the performance. ;)

AquinusYou wouldn't hate the performance. ;)

We're talking less than a clock cycle

R-T-BDo you hate your PC?

It does it all the time. Trust me.

The only reason a floating point be popped off the stack and returned as an integer is if it was instructed to... and if my PC is sentient and writing obfuscated code with integers where floats are much more logical and easier to read, input, and convert, I'm firing it.

BlueberriesThe only reason a floating point be popped off the stack and returned as an integer is if it was instructed to...

Point is, it happens all the time in programs and it is regularly done, so yeah. It's because floating point ops aren't perfectly precise while integer ops are.

That means all these security procesors tpm are completely useles.

ReadlightThat means all these security procesors tpm are completely useles.

No, it doesn't.

AquinusOnce again, it doesn't really matter either way because encryption keys aren't going to be stored in floating point registers because most cryptographic ciphers do integer math and bitwise operations. So there is absolutely no reason why something like an encryption key should be in an FP register. It literally makes no sense.

BlueberriesSingle-precision floating points are 32 bits, or 7 decimal places of precision. Almost all applications use integers or floating points, anything more would be an erroneous allocation of memory. I can't imagine a single scenario where you would need more than floating point precision for financials, but you definitely can't use integers.

BlueberriesI suppose you could but I would still hate you for doing it.

I have to add to what Aquinus is correctly pointing out. People are commonly mistaking "integer" and "float" as simply integer numbers and floating point numbers. Most programming languages use a variant of IEEE 754 in this format: a × 2 ^ b. This results in a huge range, but constant precision per exponent of 2, which means the relative precision is constant for intervals like 2->4, 4->8, 8->16, … As you can see in the Wikipedia article, the error can be as high as 20% with 7 digits of precision. Even with 64-bit float formats ("doubles"), the rounding errors can be easily exceed 0.1%, and some much higher than that. If you know anything about how exponential numbers work, you'll understand that rounding of numbers in the format a × 2 ^ b can have very large errors when either the exponent of two numbers are very different or the numbers are close enough to cause a change in exponent. You might think this "relatively small" error is still unproblematic and be close to zero in average, but when you repeatedly do multiplication or divisions, errors tend to grow exponentially. This is why the financial sector does calculation in integer datatypes with a large base number, so the rounding errors are predictable.

You can see the problem in action by pressing F12 in your web browser and do the following calculations in the console:
0.1 + 0.2
0.01 + 0.06

Now try some rounding in JavaScript:
parseFloat(55.555).toFixed(2);
parseFloat(1.3555).toFixed(3);
(just paste it into the console, line by line)


Remember that banks may calculate interest and fees monthly or even daily, these "small" rounding errors can grow exponentially when multiplying thousands of times.

This subject is actually highly relevant for software development. I've had several episodes with colleagues who insist this is a bug in the code or in the programming language, who even struggle to understand it after a detailed explanation, despite having master degrees in CS and many years of experience. The only "bug" is the programmer's lack of understanding of how theoretical math is applied to actual hardware and software, and the sad thing is that this is elementary stuff in CS.
</math_lesson>

dj-electricThe idea behind my somewhat sarcastic comment was to counter the ridicules claim that Intel's performance edge will disappear after a few security patches.

Well, keep patching and at some point those performance edge will lower. in VM systems the latest patch would seriously harm performance. We're not talking desktops here, but enterprise based on Intel hardware. The performance impact was seen there at most with meltdown and all.