Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zeroing buffers is insufficient

daemonology.net

Post reply on HN
Print view View original

101–110 of 134 posts

Re: Zeroing buffers is insufficient

#101

Post by tptacek »

pbsd wrote: post #61

> For encryption operations these aren't catastrophic things to leak — the final block of output is ciphertext, and the final AES round key, while theoretically dangerous, is not enough on its own to permit an attack on AES This is incorrect. The AES key schedule is bijective, which makes recovering the last round key as dangerous as recovering the first.

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".

Re: Zeroing buffers is insufficient

#102

Post by Nursie »

ggchappell wrote: post #92

This article makes a good point, but I think the problem is even worse than he describes. Computer programs of all kinds are being executed on top of increasingly complicated abstractions. E.g., once upon a time, memory was memory; today it is an abstraction. The proposed attribute seems workable if you compile and execute a C program in the "normal" way. But what if, say, you compile C into asm.js? Saying, "So don't…

And if I run my C program in an emulator that allows me to freeze it and dump memory I can do this stuff too...

The point is, if you want security you need to look at the whole system and in the situation you describe you can't guarantee it, no.

I'm not going to say "So don't do that", but I am going to say "If you're going to do things like that, please realise that the assumptions the system security was built on no longer hold true".

I think to do it better we just need to pay a bit more attention. And try not to let ourselves get into situations (cough heartbleed cough) where memory zeroing is actually an important feature. IE - by the time the attacker is able to read your process memory you're probably already screwed.

Re: Zeroing buffers is insufficient

#103

Post by cperciva »

tptacek wrote: post #101
pbsd wrote: post #61

> For encryption operations these aren't catastrophic things to leak — the final block of output is ciphertext, and the final AES round key, while theoretically dangerous, is not enough on its own to permit an attack on AES This is incorrect. The AES key schedule is bijective, which makes recovering the last round key as dangerous as recovering the first.

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".

Dead simple. 2nd year undergraduate programming assignment.

Re: Zeroing buffers is insufficient

#104

Post by floody-berry »

geertj wrote: post #72
AlyssaRowan wrote: post #2

It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing. Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand. The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?

This is what djb is doing using his "qhasm" assembly like language. He seems to be doing it for performance though, not to work around too aggressive compilers. As an alternative, maybe write crypto algorithms in LLVM IR?

Adding an annotation for qhasm where stack variables/registers would be zero'd at the end of the function if they still contained sensitive data would be great.

What I'd really like to see is qhasm put on github along with the syntax files he or others create. q files aren't really useful without the syntax files they were made for, and without a central repo, custom made syntaxes will be a mis-mash of random decisions and instructions.

Re: Zeroing buffers is insufficient

#105

Post by Nursie »

anon4 wrote: post #96

If I have enough control to the point where I can read your memory in some way, I can just use ptrace. Heck, I could attach a debugger. It seems ludicrous to want that level of protection out of a normal program running on Mac/Win/Linux. Now, if your decryption hardware was an actual separate box, where the user inserts their keys via some mechanism and you can't run any software on it, but simply say "please decrypt…

One of the other things you're sorta-describing is an HSM.

These are dedicated boxes that just do crypto. You keep them on the network or attached via a serial port or... whatever. Accessible to your machines but not the outside world. Then you send them messages to ask them to encrypt and decrypt data for you. That way the keys never leave the box. The HSM doesn't accept new software, nor does it ever expose the keys to anyone.

They are, however, quite expensive.

Re: Zeroing buffers is insufficient

#106

Post by Nursie »

hollerith wrote: post #100
nathan7 wrote: post #99

Earlier quoted context omitted.

What you're describing is called a smartcard, and readily available on the market. I keep my PGP key on one.

Does your PGP key stay on the smartcard or is a copy of it transferred to your computer on occasion?

If it's a properly designed smartcard system then the key never leaves the card.

Re: Zeroing buffers is insufficient

#107

Post by tptacek »

cperciva wrote: post #103
tptacek wrote: post #101

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".

Dead simple. 2nd year undergraduate programming assignment.

Is it perhaps so simple that... Colin Percival could effectively describe how to do it in an HN comment, perhaps even challenging someone like Thomas Ptacek to code it up and publish it instead of just yakking on HN like he always does I hate him so much?

Re: Zeroing buffers is insufficient

#108

Post by pbsd »

tptacek wrote: post #101
pbsd wrote: post #61

> For encryption operations these aren't catastrophic things to leak — the final block of output is ciphertext, and the final AES round key, while theoretically dangerous, is not enough on its own to permit an attack on AES This is incorrect. The AES key schedule is bijective, which makes recovering the last round key as dangerous as recovering the first.

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".

It's pretty straightforward to just iterate the key schedule backwards using the inverse S-box and a few xors; no need for any fancy stuff.

Re: Zeroing buffers is insufficient

#109

Post by Roboprog »

TheLoneWolfling wrote: post #95
MichaelGG wrote: post #91

Earlier quoted context omitted.

Not if you write the junk output to volatile variable, right?

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 = ; volatile junk = hash(decrypt(nonsense)); Into this: decrypt(real); volatile junk = ; But even if you nons…

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.

Re: Zeroing buffers is insufficient

#110

Post by danielweber »

ggchappell wrote: post #92

This article makes a good point, but I think the problem is even worse than he describes. Computer programs of all kinds are being executed on top of increasingly complicated abstractions. E.g., once upon a time, memory was memory; today it is an abstraction. The proposed attribute seems workable if you compile and execute a C program in the "normal" way. But what if, say, you compile C into asm.js? Saying, "So don't…

You remind me why it's so hard to do secure deletion: there are a bunch of abstractions built on old assumptions that no one cares about secure deletion. If you forget your pointer to that memory, it can be reused, so it's effectively deleted, we're all good, right? Meanwhile, the file you "sync"ed to disk might be synced to a network drive or flash memory or a zillion cache layers.

I think we need, right at the base metal, a way of saying "this data needs to not be copied" and/or "if you do copy it you must remember all copy locations so we can sanitize them all." And then we require every abstraction on up to have a way of maintaining this, the same way all the abstractions are required to, say, let us read data.

Or I guess this is part of what HSMs are supposed to do -- do all your "secure" work in something that is very strictly controlled.

Post reply on HN