SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 16 submissions in the queue.
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.
... A solemn, unsmiling, sanctimonious old iceberg who looked like he
was waiting for a vacancy in the Trinity.
-- Mark Twain
(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.