OpenSSH No Longer Has To Depend On OpenSSL 144
ConstantineM writes: "What has been planned for a long time now, prior to the infamous heartbleed fiasco of OpenSSL (which does not affect SSH at all), is now officially a reality — with the help of some recently adopted crypto from DJ Bernstein, OpenSSH now finally has a compile-time option to no longer depend on OpenSSL. `make OPENSSL=no` has now been introduced for a reduced configuration OpenSSH to be built without OpenSSL, which would leave you with no legacy SSH-1 baggage at all, and on the SSH-2 front with only AES-CTR and chacha20+poly1305 ciphers, ECDH/curve25519 key exchange and Ed25519 public keys."
Re:Compiler option (Score:5, Interesting)
Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.
Except that OpenSSL actually didn't run with the "feature disabled" (internal freelist-based memory allocator) due to uninitialized memory bugs in OpenSSL that required newly allocated blocks of certain types to have memory set in them from previously freed blocks. See details here [tedunangst.com].
AES-CTR (Score:5, Interesting)
I don't like AES-CTR as a privacy mode for online communications and I don't like this [bxr.su]
void
aesctr_keysetup(aesctr_ctx *x,const u8 *k,u32 kbits,u32 ivbits)
{
x->rounds = rijndaelKeySetupEnc(x->ek, k, kbits);
}
The AES key schedule can be computed inline with the round function, both for encrypt and decrypt.
Computing the key schedule inline means that the state isn't left laying around in memory.
Also, the majority of side channel attacks against key schedule rely on repeated behaviors. A simple principle that is a good mitigation is to never use the same key twice.
Pre-computing the key schedule is only an optimization when you are using the same key repeatedly.
So AES-CTR encourages both sins. Using the same key multiple times and then optimizing by keeping the key schedule state laying around.
The CTR mode is just a non-ideal PRF to generate bits that are XORed with the data. On each block the key is the same but the IV changes.
The PRF is non ideal because no block will match (since AES or any other block cipher, with a fixed key is a bijective mapping) whereas in true random data, blocks may match with the usual statistical probability.
So if we picked a better block cipher based PRF, like say the SP800-90 AES-CTR-DRBG, both key and IV change on each step, so the output looks more like a real PRF and the key isn't used twice and so there's no incentive to optimize with a pre computed key schedule.
The inline computation is nice and simple [deadhat.com] and constant time. This is a particularly inefficient implementation, you can do better:
void next_key(unsigned char *key, int round)
{
unsigned char rcon;
unsigned char sbox_key[4];
unsigned char rcon_table[12] =
{
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80,
0x1b, 0x36, 0x36, 0x36
};
sbox_key[0] = sbox(key[13]);
sbox_key[1] = sbox(key[14]);
sbox_key[2] = sbox(key[15]);
sbox_key[3] = sbox(key[12]);
rcon = rcon_table[round];
xor_32(&key[0], sbox_key, &key[0]);
key[0] = key[0] ^ rcon;
xor_32(&key[4], &key[0], &key[4]);
xor_32(&key[8], &key[4], &key[8]);
xor_32(&key[12], &key[8], &key[12]);
}
He's right when he's driving in the UK (Score:5, Interesting)
Sometimes, DJB is right, I'll give him that. More frequently, I think, he simply doesn't like following any standards, customs, or conventions. In the US, he'd come up with an argument of why driving on the left side of the road is better. If the same discussion occurred in the UK, he'd come up with an equally good argument why people should drive on the right side of the road - whatever position is contrarian, he'll take it. That's fine, it helps avoid groupthink and the like. The problem is, he doesn't just argue it - he then goes right on ahead and actually drives on the wrong side of the road. Left or right probably doesn't matter, but going head-on against all of the traffic is obviously a very bad idea, and that's what he does.
A well known example is of course the filesystem. The Linux Standards Base discussions covered a few options that each had minor benefits and drawbacks. It didn't really matter what LSB decided - the config files can be in /etc/ , in /config/, or in /why/cares/ - it doesn't matter as long as you know where they are so you can back them up, adjust them for a new instance of an image, etc. What matters most isn't where they are, but that they are in some standard location. DJB screws all that up. I suspect that half the time, the perverse pleasure of screwing up standards is actually his primary motivation for his decisions.