SoylentNews is people
SoylentNews
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, the option `make OPENSSL=no` has now been introduced for a reduced-configuration OpenSSH to be built without OpenSSL.
The result 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.
[Editor's Note: This appears to be very much a Work-in-Progress, so might not be available for your distro or via standard repositories.]
This discussion has been archived.
No new comments can be posted.
OpenSSH No Longer has to Depend on OpenSSL
|
Log In/Create an Account
| Top
| 14 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Just because the message may never be received does not mean it is
not worth sending.
(Score: 2) by mmcmonster on Thursday May 01 2014, @01:37PM
I'm not sure I like this. Why should OpenSSH roll their own version of these crypto routines. Crypto is both hard and important, and the idea of having it be taken care of by a common library is so that the library can be audited and any bugs squashed to everyone's benefit.
Admitted the practice left something to be desired, but with the advent of Heartbleed and the Snowden issues, crypto security is at least on the radars of the major distributions.
(Score: 2, Interesting) by Anonymous Coward on Thursday May 01 2014, @02:02PM
The era of "crypto is hard, don't write crypto, always use a library" needs to stop. Crypto math is hard, crypto-systems (identifying the right primitives to use to establish a secure protocol) are hard, and protection against side-channel attacks is hard. Let the experts develop those and come up with best practices, fine.
But crypto primitives are easy: there are known test vectors, if your code produces the right output for the inputs then it is correct. There is nothing magic about it, the code for most functions (hash, encrypt, decrypt, sign, PRNG) is a few hundred lines each. We should not be scared to write that code, because only by a bunch of us trying do we evolve good practical APIs to swap out those libraries, both for primitives and full crypto-systems.
For crypto-over-the-wire, we need to move to a model of multiple different crypto-system libraries running the same network bytes and requiring agreement before transmitting anything to the other side. For that we should have native-language crypto (not just bindings to (open|libre)ssl/libgcrypt/libcrypto++) for every language with socket support in its standard library (e.g. Java, C#, C (on POSIX/Win32), D, ...) and an inter-process API so that the SSL/TLS/etc stuff doesn't happen in the same address space as the actual user data. Basically apply the mentality of SIL-rated systems to network crypto.
(Score: 1) by cnst on Thursday May 01 2014, @02:04PM
But OpenSSH is not inventing their own crypto routines -- they're using those invented by DJB a couple of years back (and which have now been part of OpenSSH for a couple of months and two releases so far), instead of having to rely on the spaghetti that is OpenSSL.
(Score: 0) by Anonymous Coward on Friday September 12 2014, @04:22PM
95qcry cdzwvjvtxjbv [cdzwvjvtxjbv.com], [url=http://icrmeffnochz.com/]icrmeffnochz[/url], [link=http://fgmkpvgabhqj.com/]fgmkpvgabhqj[/link], http://piclrlcxvkpx.com/ [piclrlcxvkpx.com]