131–134 of 134 posts
Earlier quoted context omitted.
How hard is that attack to code? I have a hard time imagining a case where a target leaks just a subkey, so this is one of those things I knew "about" but not "how".
cperciva already answered, so I'll just add that most side-channel attacks (at least those using power analysis) on AES typically focus on the last round.
Part 2 is correct in that trying to zero memory to "cover your tracks" is an indication that You're Doing It Wrong, but I disagree that this is a language issue. Even if you hand-wrote some assembly, carefully managing where data is stored, wiping registers after use, you still end up information leakage. Typically the CPU cache hierarchy is going to end up with some copies of keys and plaintext. You know that? OK, t…
The suggestion has the right idea, but the wrong implementation. The developer should be able to mark certain data as "secure" so the security of the data travels along the type system. Botan, for example, has something called a "SecureVector" which I have never actually verified as being secure, but it's the same idea.
This was my initial idea, but talking to compiler developers convinced me that the dataflow analysis needed for this would be tricky. They were much happier with the idea of a block-scope annotation.
Try: #include void bar(void *s, size_t count) { memset(s, 0, count); __asm__ ("" : "=r" (s) : "0" (s)); } int main(void) { char foo[128]; bar(foo, sizeof(foo)); return 0; } gcc -O2 -o foo foo.c -g gdb ./foo ... (gdb) disassemble main Dump of assembler code for function main: 0x00000000004003d0 : sub $0x88,%rsp 0x00000000004003d7 : mov $0x80,%esi 0x00000000004003dc : mov %rsp,%rdi 0x00000000004003df : callq 0x400500 0…