5 ms·

Doesn't actually seem true. OK, running the decrypt leaves the key and data in SSE registers that are rarely used where it might be looked up later by attackers

by lnanek2 12y ago

Doesn't actually seem true. OK, running the decrypt leaves the key and data in SSE registers that are rarely used where it might be looked up later by attackers. There isn't any portable way to explicitly clear the registers. Then why not just run the decrypt again with nonsense inputs when you are done to leave junk in there instead? Yes, inefficient, but a clear counter example. You could then work on just doing enough of the nonsense step to overwrite the registers.

lifeisstillgood 12y ago
That's just a workaround though. It still does not invalidate the basic thrust "I can't write code to handle keys in C and be sure I have not left copies anywhere" The proposal seems goods
TheLoneWolfling 12y ago
> Then why not just run the decrypt again with nonsense inputs when you are done to leave junk in there instead? Because the compiler is perfectly within its rights to optimize that out!
- MichaelGG 12y ago
  Not if you write the junk output to volatile variable, right?
  - TheLoneWolfling 12y ago
    Let me clarify. If you use a deterministic nonsense value, the compiler can turn the result of decrypt(nonsense) into a constant at compile time, and just directly output the constant to the volatile variable, without actually ever calling decrypt again at runtime. So it can turn this: decrypt(real); nonsense = <whatever>; volatile junk = hash(decrypt(nonsense)); Into this: decrypt(real); volatile junk = <the appropriate constant value>; But even if you nonsense is non-deterministic (although I question where you are getting the entropy - if you're using a syscall / random / etc your performance has potentially just gone out the window), the compiler is well within its rights to optimize the second junk decrypt of the nonsense input differently than the first (real) decrypt - in such a way that it does not overwrite everything left behind by the first decryption. (Same with encryption)
    - Roboprog 12y ago
      I think the "slowness" aspect of "do it twice" is a given, making the best of a bad situation. Clearly, the people who want languages or hardware to do this "right" have a better solution, but if you have to get by with C on existing hardware, it would seem that an option in a library to select further security at less speed is reasonable. Of course assuming said option runs code that won't be optimized away.

by lnanek2 12y ago

lifeisstillgood 12y ago

That's just a workaround though. It still does not invalidate the basic thrust "I can't write code to handle keys in C and be sure I have not left copies anywhere" The proposal seems goods

TheLoneWolfling 12y ago

> Then why not just run the decrypt again with nonsense inputs when you are done to leave junk in there instead? Because the compiler is perfectly within its rights to optimize that out!

MichaelGG 12y ago
Not if you write the junk output to volatile variable, right?
- TheLoneWolfling 12y ago
  Let me clarify. If you use a deterministic nonsense value, the compiler can turn the result of decrypt(nonsense) into a constant at compile time, and just directly output the constant to the volatile variable, without actually ever calling decrypt again at runtime. So it can turn this: decrypt(real); nonsense = <whatever>; volatile junk = hash(decrypt(nonsense)); Into this: decrypt(real); volatile junk = <the appropriate constant value>; But even if you nonsense is non-deterministic (although I question where you are getting the entropy - if you're using a syscall / random / etc your performance has potentially just gone out the window), the compiler is well within its rights to optimize the second junk decrypt of the nonsense input differently than the first (real) decrypt - in such a way that it does not overwrite everything left behind by the first decryption. (Same with encryption)
  - Roboprog 12y ago
    I think the "slowness" aspect of "do it twice" is a given, making the best of a bad situation. Clearly, the people who want languages or hardware to do this "right" have a better solution, but if you have to get by with C on existing hardware, it would seem that an option in a library to select further security at less speed is reasonable. Of course assuming said option runs code that won't be optimized away.