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.
People need to reinvent the wheel more. It creates diversity.
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.
https://xkcd.com/927/
#DeleteChrome
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.
funny how this is perfectly accepted in RL in airports.
I think it's because TSA screening actual goal is get the sheeple accustomed to be harassed by their government.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
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.
With magic numbers provided by the NSA?
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.
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.
are shit. He's doing us a favor by rejecting the bullshit that we mindlessly follow in the industry.
Compatibility isn't a reasonable justification for doing things wrong. But pretty much every professional job I've had forced me to pretend that was not the case. So honestly I envy DJB and I strive to be intellectually honest about the baloney that my peers try to feed me.
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.
And neither will the next president, *regardless* of which side of the 'one party, two faces' system they claim to be in.
FTFY: 'one party, two feces'
-- I ignore anonymous replies to my comments and postings.
RSA? Seriously? You've got to be the last person on Earth asking for more RSA after seeing the Snowden revelations.
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.
HIs revelations raised concern about backdoors hidden by NSA and in recent months a lot of auditing of crypto libraries and improving RNGs has been done in open source software. NSA will have a hard time finding new flaws with widely used remote protocols (local exploits are another matter, as attack surface is much larger).
Always ride Double Deuce Airlines: For when you just have to be sure that shit flies!
Compatibility isn't a reasonable justification for doing things wrong.
Yet here you are, typing in the cumbersome and ambiguous natural language that is English, merely for compatibility.
Actually the work to make this happen has been ongoing earlier this year but predates heartbleed. For example:
Changes by: djm@cvs.openbsd.org 2014/01/09 16:20:01
Modified files:
usr.bin/ssh : hostfile.c kex.c kex.h kexc25519.c kexc25519c.c
kexc25519s.c kexdh.c kexecdh.c kexecdhc.c
kexecdhs.c kexgex.c kexgexc.c kexgexs.c key.c
key.h roaming_client.c roaming_common.c
schnorr.c schnorr.h ssh-dss.c ssh-ecdsa.c
ssh-rsa.c sshconnect2.c
usr.bin/ssh/lib: Makefile
Added files:
usr.bin/ssh : digest.c digest.h
Log message:
Introduce digest API and use it to perform all hashing operations
rather than calling OpenSSL EVP_Digest* directly. Will make it easier
to build a reduced-feature OpenSSH without OpenSSL in future;
feedback, ok markus@
But of course you didn't know that. You are just too motherfucking ignorant and your zeal to bash OpenBSD for anything they do shows it.
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.
This is either a problem or a feature, depending on your systems.
Good thing it is optional, so you do not even have to whine about it not fitting _your_ use-case, because you do not have to use OpenSSH(minus)OpenSSL. you can go with another SSH implementation. Being smart as you are, you pick the solution that fits your situation, if you need legacy support you do not pick a non-legacy-supporting option, unless you are stupid or a specific software fanboy/hater.
Are you mad they didnt write your special case software for free for you?
Most - if not all - the people active in this have made close to 0 effort to publicise it outside the usual OpenBSD related lists/forums/blogs. If it is politicial it is due to someone else making it so, probably because they hate secure software from a freedom loving team.
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.
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.