OpenSSH No Longer Has To Depend On OpenSSL 144
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."
Nooooooooo (Score:5, Funny)
Sorry, I'll take OpenSSL over any DJBness any time!
Re:Nooooooooo (Score:5, Insightful)
DJB is the worst kind of asshole too: he's almost always right. So you shouldn't just ignore him. Meh, justified arrogance still annoys.
Now, what we really need is a cage match between DJB and Theo de Raanter. I'd buy that on PPV!
Re: (Score:3)
Now, what we really need is a cage match between DJB and Theo de Raanter. I'd buy that on PPV!
Might be kinda boring, actually - they're both usually harsh on people who are wrong. So, in this case...
You'd have to get DJB talking about large systems integrations (awesome, qmail is a secure system that doesn't meet real world needs without patches of unknown quality) and Theo talking about people's motivations (especially 'linux people').
He's right when he's driving in the UK (Score:5, Interesting)
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.
Re: (Score:1)
he'd come up with an argument of why driving on the left side of the road is better.
That's because it is :oD
Re: (Score:2)
that depends entirely on your geography. If, for instance, you try that in, say, Los Angeles... you're going to die horribly. Try it in a rural country road in England, and you'll be just fine.
Re:He's right when he's driving in the UK (Score:5, Funny)
Driving around "country roads" in Scotland, I was left with the impression that they don't really have "sides". You just go along down the middle until you come across an oncoming car, then rock/paper/scissors to decide who is going to back-up to a spot wide enough for two cars to pass or just pull into the sheep field. These "country roads" also seemed to be the most direct route from one place to another.
Re:He's right when he's driving in the UK (Score:4, Insightful)
Because he's Dr. Daniel J Bernstein, Phd (Score:2)
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.
Re: (Score:1)
Re: (Score:2)
As someone with a phd who works around people with phd degrees, the phrase "just not half as smart as he thinks he is" has very wide applicability.
"OK, so you have a PhD. Just don't touch anything".
Re: (Score:3)
I would argue, it's not that he's *right*, it's that he's right in a way that still doesn't help.
Wife: "Honey, do you know where my keys are?"
Husband: "Pretty sure they're right where you left them!".
Technically correct, completely unhelpful.
And that's how QMail is. (or was, I stopped using it years ago) Qmail is a nightmare I'd rather forget. Sure, it is/was very secure, modularly written with strong privilege separation, built-in clustering support, etc. But because of the horribly restrictive license it
Re: (Score:1)
_almost_
His approach to mail was downright abusive.
Opening dozens of parallel connections to a target if there are multiple recipients instead of using multiple RCPT TO:, and SMTP streaming for multiple messages amounted to a Denial of service attack on larger mailservers.
In postal terms the postman is carrying a 165mm breaching cannon and is intoning "the mail MUST get through" as he blasts new holes in your structure to take the shortest possible path.
Re: (Score:2)
Re: (Score:2)
It "worked" only as long as you don't care about the problems DJB had no interest in solving. It is true that you can't use Qmail to break into the host system, but unfortunately you can use it as a reflector and annoy the crap out of pretty much everyone else.
I was a Qmail fan and installed it everywhere I worked right up until the day several of my servers got blacklisted.
Re: (Score:2)
Really, I've run it for at least the last 15 years and have not once been blacklisted. I follow the words of a great American, Ronald RayGun: Trust but verify.
Re: (Score:1)
If you set it up as an open relay, then you did it wrong. If you didn't disable the bounce mail, then you did it wrong. The problem here wasn't qmail, it was the guy that set it up. PEBCAK.
Re: (Score:3)
Your suggested fix to disable bounce messages with the side affect that the sender then has no way to know that the mail never arrived? Not going to happen. If I ever did something that stupid, my clients would drop me.
In the meantime I've switched to Postfix which manages to do things correctly by refusing the message in the initial connection if the user doesn't exist so the sending mail server gets to generate the bounce message instead. And yes I know there are now patches and Qmail forks that cause
Re: (Score:2)
QED.
Re: (Score:2)
Re: (Score:2)
I only posted because it is an elegant solution that provides some amazing features... uh... elegantly. But it is new, and the main feature is mitigated somewhat in ssh by screen. More often than not, I do get annoyed by ssh latency, for which mosh has an... uh.. elegant... solution. (sorry, its late...uh... early)
However, even still, the license is absolutely unacceptable for some uses.
I never thought that the GPL would cause a particular use to be counter to the licensing unless it was being used as a component in another application by a developer that necessarily needed to
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
No i'm not mad I just don't see this option as very useful at this point.
Re: (Score:2)
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 o
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Vetting the replacement libraries? (Score:5, Insightful)
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?
Re:Vetting the replacement libraries? (Score:4, Informative)
LibreSSL will indeed, by used by OpenSSH.
See here for more details: http://undeadly.org/cgi?action... [undeadly.org]
Re:Vetting the replacement libraries? (Score:5, Informative)
There are no replacement libraries. The ED25519, ECDH, ChaCha20 and AES-CTR code is all part of OpenSSH itself. And the code is very, very tight and compact and very easy to audit. Entirely the opposite of OpenSSL!!!
Good news! Now get it FIPS certified. (Score:4, Insightful)
Get this version of OpenSSH FIPS certified and it will be default industry standard for the next decade.
Re: (Score:1)
I have a feeling the openbsd team do not particularly care for FIPS certification at this point in time. O:-)
http://opensslrampage.org/post/83555615721/the-future-or-lack-thereof-of-libressls-fips-object
Re: (Score:2)
What's the industry standard of this decade?
Re: (Score:2)
We still have six more years to go, so I think either the next standard or the third one after that.
Re: (Score:3)
Or, as the fortune used to read: The good thing with standards is that there are so many of them to choose from...
Re: (Score:2)
no, FIPS does not meet the approval of those who deal in securing communications, it has dubious/poor security protocols included. that's why the OpenBSD team threw it out of LibreSSL. Past time to get rid of symbolism over substance in the realm of security.
Re:symbolism over substance in the realm of secury (Score:1)
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.
Re: (Score:2, Insightful)
Re: (Score:2)
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.
Re:symbolism over substance in the realm of secury (Score:4, Funny)
FTFY: 'one party, two feces'
Re:Good news! Now get it FIPS certified. (Score:5, Insightful)
Re: (Score:2)
Large city police departments are already pushing back at FBI for their lagging technical crypto requirements.
Re: (Score:2)
You would concede that authenticating a us-government criminal database is irrelevant for the vast majority of internet traffic.
Such functionality doesn't belong in a core crypto library for linking against the thousands of software packages that make up the OpenBSD ports collection - which otherwise don't require it to work.
Maintain it as an add-on module if you must. It should be disabled by default unless a user specifically requires said functionality.
Re: Good news! Now get it FIPS certified. (Score:2, Informative)
You can't certify source code. You can only certify binaries. That makes FIPS certification a challenge for most users and implementers.
Re: (Score:2)
25519, chacha20 and poly1305 are not FIPSable algorithms.
Re: (Score:2)
Hmm. Interesting. Could you please back this assertion with references?
I am not trolling in any way - just trying to figure out why these algorithms are not certifiable.
Re:Good news! Now get it FIPS certified. (Score:5, Informative)
FIPS 140-2 [nist.gov] is a spec about boundaries. You draw a boundary and the spec talk about how data passed through the boundary and about the stuff that allowed inside the boundary.
One the primary things is asks is that the crypto algorithms are NIST approved. E.G. AES or SP800-90 or SHA1/2/3.
So to build a FIPS140-2 compliant thing, you first determine the box (the boundary) and the function. Then implement that function using crypto algorithms from the list of NIST approved algorithms.
Curve 25519, chacha20 and poly1305 do not appear in any NIST published specification.
Re: (Score:2)
OK, thank you for that information.
Re: (Score:2)
Apologies for the huge number of typos I managed to fit into that response.
Re: (Score:3)
Not all of them. For example in SP800-90 the AES-CTR-DRBG has publicly published proofs of its security. Also I understand the hash and hmac DRBGs to be secure but I've never read the proofs.
The sore thumb was the Dual-EC-DRBG which was suspect from day one and shown to have a back door in 2006.
I myself pointed out the back door in FIPS140-2 section 4.9.2 that I call the "FIPS Entropy Destroyer" and I refused to implement it and I've submitted comments to NIST to fix it in the spec.
SHA1 is broken. SHA2 is s
Compiler option (Score:1)
So, OpenSSH has now a compiler option to disable OpenSSL. OpenSSL had a compiler option to disable heartbleed. Did it help?
Re: (Score:2)
Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.
Re:Compiler option (Score:5, Interesting)
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 [tedunangst.com].
Re: (Score:2)
I'm not sure I understand. Surely the feature must have been disabled if it was not built as part of the binary?
OPENSSL_NO_HEARTBEATS (Score:1)
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.
Re: (Score:2)
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
Re: (Score:2)
OPENSSL_NO_HEARTBEATS has since been made the default and only option in LibreSSL, and the heartbeats were removed.
Too bad, heartbeats are quite useful in DTLS context. Yanking useful features just because someone screwed up in implementation space is not a rational response.
Re: (Score:2)
Although in the DTLS can be trivially implemented within the app rather than transport layer
The point is to provide useful UDP compatible semantics so **existing** UDP protocols are able to leverage DTLS. In the UDP world concept of an underlying session needing to be maintained prior to transporting bytes is non-existent.
For example syslog over DTLS is one-sided. Without ability to detect aliveness of encrypted session messages would be forever black holed if session died or NAT state expired.
Obviously if built from ground up you can implement anything. Use of keep-alive for MTU probe and enc
Re: (Score:2)
In the end this "useful" feature was kicked because it was flawed from the ground up at least for a security focused use and iirc only OpenSSL provided an implementation of that specific protocol so it couldn't have been that useful.
Sentiment seems to reflect a failure to understand the difference between TLS and DTLS. On a relative basis nobody uses DTLS either not sure where this leaves the "useful" argument.
The biggest mistake in my view was deploying this feature at all for TLS as there was nothing to be gained by doing so. DTLS is a completely different matter and even there they could have used a more conservative default without inconveniencing anyone.
Not to forget that this feature could be freely accessed by just about anyone as it lacked authentication
DTLS layer Keepalives post session setup are integrity protected and can't b
Re: (Score:2)
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.
But even with OPENSSL_NO_HEARTBEATS, if you are using a faulty allocator that lets you read data that has already been freed, you will still may be able to come up with other exploits (which are highly likely to exist in complicated software) that will let you read that data that you thought was "gone".
No RSA? (Score:3)
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.
Re: (Score:1)
Re: (Score:2)
I'd sooner fix the symmetric crypto. That's more my area of expertise. But the point is well taken.
However one good algorithm is better than 3 choices in security critical applications like this.
All that ciphersuite negotiation, build configuration and other stuff is just attack surface.
So I don't know it would help to add RSA. It would help to pick RSA as the only asymmetric algorithm.
Re: (Score:1)
Elliptic Curves are a minefield you need a degree in math to navigate. I prefer my crypto to be tractable.
Elliptic curve cryptography (ECC) is great. It uses small keys (32 bits) and is computationally inexpensive to implement. What's not to like? It's not a minefield, it's a field of integers [wikipedia.org].
p=2^255-19 is a prime number: 57,896,044,618,658,097,711,785,492,504,343,953,926,634,992,332,820,282,019,728,792,003,956,564,819,949. A nice big one, and that's why the crypto is secure. If I take all the integers 1,2,,p, it's a finite set. I can define a mathematical operation that, for any pair of these integers, give
Re: (Score:2)
The NSA has been heavily promoting ECC. [ietf.org]
>So start using ECC and give the NSA the finger
I don't want to give the NSA the finger, or rather that's not my primary job. I do want to develop secure products regardless of the NSA, that make it into that hands of many people, who then enjoy secure computing without having to get involved in the fight. The NSA is a great help in some ways and an undermining force in other ways. As professionals we have to deal with that reality. Delivering secure solutions in mas
Re: (Score:2)
Re: (Score:2)
So start using ECC and give the NSA the finger.
If you want to be superstitious about ECC, suit yourself. I have no doubt that the NSA would like to discourage the use of ECC and curve 25519 in particular.
Actually, they promote elliptic-curve cryptography. All of the Suite B asymmetric ciphers have moved from factoring problems to elliptic-curve ones.
Now, that leaves people in a sticky situation. See, they have some reason to distrust ciphers promoted by NSA. But NSA used to promote using DH/RSA.
Mathematicians in the public space have been making interesting progress in solving the factoring problem. Quantum computers, which can probably solve factoring problems efficiently, have started to appear in very li
Re: (Score:2)
Been serving us well for 40+ years, don't see why we should throw that away when - for instance - there still isn't a "break" in modern such encryption to leverage.
EC will be trusted when it's been around for 30+ years AND certified for military usage. PKE took at least 20 to get established in mainstream usage even without any real competition. By comparison, EC looks like a pimply teenager.
Re: (Score:2)
Right - 25519 [cr.yp.to] in particular is well-regarded. It may be that everybody in the field[sic] is wrong, but at this point it's considered stronger than RSA, and possibly resistant to quantum attacks which RSA is not.
Looking at risks today, it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks. We are not just looking at algorithms here, but implementations.
If I were on OpenBSD I might feel comfortable using LibreSSL with guard pages, but for my linux-to-linux machines in a gl
Re: (Score:2)
>it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks
Agreed. Don't use OpenSSL's RSA code. I'd choose to implement a fixed function, fixed key size, reasonably constant time RSA. Options in crypto software suck.
Re: (Score:2)
25519 is nice and all, but in the minds of people who have to make products, that's mostly because it deftly works around the very FUDy patent issues.
The minutiae of the other benefits are not gating for 25519 or any other useful curve.
But what it is not is mature. RSA is.
Re: (Score:2)
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.
How about reducing problems (Score:3)
Just create a crypto library and make OpenSSH and LibreSSL depend on that instead of duplicating hard to debug code everywhere.
Re: (Score:2)
There is always RSAREF 2.0, which has not had anyone find any major holes in it since 1994. However, it only supports RSA, and not newer algorithms like AES.
Re: (Score:2)
I should have clarified things: RSARef is a reference library for RSA. Code for modern symmetric algorithms like AES and such would have to come from somewhere else.
However, RSA's code has seemed to stand the test of time well, so it might be worth using, assuming no licensing issues.
Re: (Score:2)
AES isn't a replacement for RSA, they perform very different functions.
Yup. For those who don't know, the main difference is that RSA uses a private key to encrypt the communications and a public key for decrypting. AES uses the same key for encryption and decryption.
Re: (Score:3)
If you pick only one variant of one algorithm for each of the algorithms types, the code is very small and simple and doesn't need to be in a library, that typically needs to support many configurations for many consumers.
If you have a crypto application, write your algorithm one way, once with no configuration or runtime variation. It will serve you well.
Obligatory xkcd (Score:1)
https://xkcd.com/927/ [xkcd.com]
Very cool! (Score:1)
Not a bad thing, but not that important (Score:2)
Re: (Score:3)
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.
AES-CTR (Score:5, Interesting)
I don't like AES-CTR as a privacy mode for online communications and I don't like this [bxr.su]
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 [deadhat.com] 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]);
}
Rock the boat! (Score:2)
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 tha
Re: (Score:2)
Re: (Score:3)
Because when you invoke AES with the same key many times, you leave yourself more vulnerable to side channel and fault injection attacks.
Re: (Score:2)
In AES-CTR you use the same key in each block with a different, incrementing IV. Then XOR the output with the data.
This is algorithmically secure, because you would need more blocks than there are atoms in the universe to break the algorithm.
However each time you invoke AES with the same key, the key schedule software or circuit goes through the same sequence, leaving it open to statistical sidechannel analysis or fault injection analysis.
Re: (Score:2)
Re: (Score:2)
Yes. It's not the algorithm that's a problem. It's its vulnerability to sidechannel analysis, putting the key schedule through the same sequence each time.
Re: (Score:2)
That crap is years old and has been in many products. You'll find it in linux drivers.
Re: (Score:2)
Here: http://icanhazdigitalsecurity.... [tumblr.com]
Where is arcfour? (Score:2)
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
Re: (Score:3)
Dead. Where it belongs.
Patrons? (Score:5, Informative)
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.
Re: (Score:2)
OpenSSH vulnerability (Score:2)
Re: (Score:2)
That's the Dual-EC-DRBG that has magic numbers.
The 25519 spec describes the source of all the constants.