Slashdot Mirror
OpenSSH No Longer Has To Depend On OpenSSL
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."
Sorry, I'll take OpenSSL over any DJBness any time!
Now, here is the secondary question: How well vetted/audited will the replacement libraries end up? Disconnecting OpenSSH from OpenSSL does help isolate things, but it also means that there is twice the cryptographic code to sift through in order to ensure security.
I trust the OpenBSD developers and Theo, so IMHO, this is a net security gain.
Maybe for the lost ciphers, it might be good to implement LibreSSL?
Get this version of OpenSSH FIPS certified and it will be default industry standard for the next decade.
Can we have it with Normal RSA for key agreement/key exchange?
Elliptic Curves are a minefield you need a degree in math to navigate. I prefer my crypto to be tractable.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Just create a crypto library and make OpenSSH and LibreSSL depend on that instead of duplicating hard to debug code everywhere.
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.
Grr.. s/exactly which/exactly why/
If only there were some way to, you know, see your post before you post it. Like a "preview" button or something.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I don't like AES-CTR as a privacy mode for online communications and I don't like this
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 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]);
}
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I like it how you listed it as Obama's Legacy. TSA was put in under Bush's reign of stupidity and the NSA has been around since sometime after WWII.
In reality, the heartbeats had no place in OpenSSL; if you want a heartbeat, you can implement it on the next layer up the stack, and this should be enough to hold the connection open. In the few instances where a heartbeat has helped me, there was a better way to handle the situation (as it was usually required due to bad router configuration in the first place). Implementing transport connection quality monitoring code inside a transport encryption library just leads to stuff like heartbleed. LibreSSL is reimplementing it correctly.
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.
Dead. Where it belongs.
FTFY: 'one party, two feces'
-- I ignore anonymous replies to my comments and postings.
The front page of openssh.org is a grimy reading:
This list specifically includes companies like NetApp, NETFLIX, EMC, Juniper, Cisco, Apple, Red Hat, and Novell; but probably includes almost all router, switch or unix-like operating system vendors. In the 10 years since the inception of the OpenSSH project, these companies have contributed not even a dime of thanks in support of the OpenSSH project (despite numerous requests).
So there we go again. Even a critical piece of software like this, cannot get proper funding from the giants, who are happy to take the software for free.
It just sucks, man.
Does anyone knows if this vulnerability impacts OpenSSL implementation in OpenSSH ? http://pastebin.com/gjkivAf3