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.
So, OpenSSH has now a compiler option to disable OpenSSL. OpenSSL had a compiler option to disable heartbleed. Did it help?
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.
If your project only needs SSH, having OpenSSL is an overkill.
Just create a crypto library and make OpenSSH and LibreSSL depend on that instead of duplicating hard to debug code everywhere.
is not political when project which has focused on securing communication and servers and have proven track record are ponying up and actually *doing the work*. you're the one making political nonsense.
Small is better!
The parts of libopenssl that OpenSSH depends on are the least likely to be problematic anyway. All it really uses are the cipher implementations. Actually, the fact that the dependency surface is so small is exactly which it could be easily replaced.
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.
You're referring to the exploit-mitigation-mitigation in OpenSSL, which indeed couldn't be disabled, as per tedu@openbsd, but OPENSSL_NO_HEARTBEATS was a separate option that noone has volunteered to claim of not working.
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
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.
That's the Dual-EC-DRBG that has magic numbers.
The 25519 spec describes the source of all the constants.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Where is the arcfour cypher? You can't not include the fastest cypher there is for bulk data transfer.
for i in aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour128 arcfour256 arcfour aes192-cbc aes256-cbc aes128-ctr; do echo $i; dd if=/dev/zero count=1000000 2> /dev/null | ssh -Cc $i 127.0.0.1 "dd of=/dev/null"; done
Hi,
thank you, that's a similar bad feeling I carried arround with me everytime hearing AES-CTR.
The further interesting analysis on AES-CTR encrypted traffic would be if when the data is not appearing to be "random" enough,
if you could recognize patterns inside the data and then resolve back to the encrypted data.
Like the famous ECB encrypted pengiun could still be recognized attacks. [1]
It would even introduce a lower level of
a.) you transer your passwords file over openssh
b.) I recognize the pattern of that file
= Will start working on that specific data, perhaps the machine juice needed would be out of the question for a normal individual. But the real crypto attackers are not normal individuals, super power computing power is at hand.
[1] http://en.wikipedia.org/wiki/C...
If your project only needs SSH
And you control the software versions on all the clients/servers you will be interoperating with.
AIUI (from a compbination of the summary and my memory) if you enable this option you will end up with a ssh client/server that will have serious interoperability problems due to only supporting crypto options that are very new.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
You are branded with the shit you inherit, embrace, extend, and stand for. You're either part of the problem or part of the solution, and Obama has solved NOTHING.
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.
Because he's DOCTOR Daniel J. Bernstein, PhD. The PhD means he's the only person with a clue, that he knows much better than everyone else who has ever lived. Therefore, qmail stores its config files in /var.
DJB IS a smart guy - just not half as smart as he thinks he is.
It's a matter of timing. This has been in the pipeline for a while; it got pushed through with immediacy as a political move. Reread the whole statement: this has been a long time coming, but it only happens at a critical political moment. Like Congress sitting on an important bill to provide mental healthcare and treatment for pedophiles for 8 years until there's a high-profile child murder-rape by an individual who obviously caved under the stress of his urge, and then passing it in a powerful show of strong, effective leadership.
Support my political activism on Patreon.
It's political when you're "going to do it" for years and then, the moment you can lord it over someone you don't like and show off how great you are, you finally pull the trigger and shout out to everyone how great you are.
Politics, like Go, is not about the precise action; it's about the timing of that action.
Support my political activism on Patreon.
There is RSA the algorithm and RSA the company. They are related in the sense that the people who came up with the algorithm founded the company but the founders sold off the company over a decade ago.
Whether to trust the RSA algorithm and whether to trust RSA security are not really related issues.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
No i'm not mad I just don't see this option as very useful at this point.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Does anyone knows if this vulnerability impacts OpenSSL implementation in OpenSSH ? http://pastebin.com/gjkivAf3
please provide link to past years when openbsd said "they're going to do it".
please provide link to where they said after heartbleed how great they are.
instead, they dived in and did WORK. they have action to back up their words. ou are the one being political, what contribution to communication security have you ever made? you just shoot off metaphorical forum mouth about others actually accomplishing something, while contributing nothing yourself. textbook political-only behavior
The summary has a link titled "planned for a long time now". Scroll to the top of the page...
Support my political activism on Patreon.