Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenSSH No Longer Has To Depend On OpenSSL

Soulskill posted about 6 months ago | from the like-independence-day,-but-for-communications-protocols dept.

Encryption 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."

cancel ×

144 comments

Sorry! There are no comments related to the filter you selected.

Nooooooooo (5, Funny)

sholdowa (242332) | about 6 months ago | (#46882925)

Sorry, I'll take OpenSSL over any DJBness any time!

Re:Nooooooooo (5, Insightful)

lgw (121541) | about 6 months ago | (#46883409)

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:Nooooooooo (2)

bill_mcgonigle (4333) | about 6 months ago | (#46883659)

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 (5, Interesting)

raymorris (2726007) | about 6 months ago | (#46884379)

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:He's right when he's driving in the UK (1)

Anonymous Coward | about 6 months ago | (#46885801)

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:He's right when he's driving in the UK (1)

radiumsoup (741987) | about 6 months ago | (#46886097)

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 (3, Insightful)

hangareighteen (31788) | about 6 months ago | (#46885839)

His goal seems to be to make rock solid software with well-considered security of design and operation, and that's about his only goal. Compliance with the LSB is nice and all, but it's not something that keeps me up at night. Hell, it's not even in the top ten; and while DJB's software can be a little rough around the edges, I'm more than happy to use it because I have a high level of confidence in the design and implementation of his ideas.

Re:He's right when he's driving in the UK (0)

Anonymous Coward | about 6 months ago | (#46886325)

Actually his rock solid security is just hype. Qmail in particular had exploitable bugs for years that you had to get patches for because DJB refused to admit they were there. He's a shameless self promoter and little else.

Most technical standards, customs and conventions (0)

Anonymous Coward | about 6 months ago | (#46886213)

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.

Re:He's right when he's driving in the UK (0)

Anonymous Coward | about 6 months ago | (#46886483)

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.

For 40+ years now unix configuration files have been stored in /etc/ (or a subdirectory thereof), why on earth would someone change that?

Re:Nooooooooo (1)

OffTheLip (636691) | about 6 months ago | (#46883587)

Queue the 'q'mail haters but djb stuff worked.

Re:Nooooooooo (0)

Anonymous Coward | about 6 months ago | (#46883717)

Until it didn't. I had to work for a DJB fanboy, and the nightmares of integrating djbdns, daemontools, and qmail into any kind of sensible layout was nightmarish. His "the top of / belongs to me and any topo level directories I'd care to shove into it, unprotected and without even flowers or a bit of lube" was problematic for any stable environment. He's one of those "architects" who can't be bothered to read or follow any spec he didn't invent himself. The results were predictable.

Re:Nooooooooo (1)

Ice Station Zebra (18124) | about 6 months ago | (#46885235)

QED.

Re:Nooooooooo (1)

gmack (197796) | about 6 months ago | (#46884029)

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:Nooooooooo (1)

Ice Station Zebra (18124) | about 6 months ago | (#46885263)

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:Nooooooooo (1)

catmistake (814204) | about 6 months ago | (#46884557)

I won't miss OpenSSL and that tiny ragtag team of developers, the OpenSSL Eight, as impressive as their work is for such a tiny crew. And I'm only responding because I don't see anyone complaing about ssh, and it is dear to my heart, too, but maybe its time for a change [wikipedia.org] ... becuase now there is mosh [mit.edu] ..

Re:Nooooooooo (0)

Anonymous Coward | about 6 months ago | (#46885687)

The referenced Wikipedia page identifies mosh as "GNU GPLv3 with OpenSSL and iOS exceptions"
Those OpenSSL exceptions are likely to be even less relevant as OpenSSL gets replaced with the library re-implementing SSL (libReSSL). However, even still, the license is absolutely unacceptable for some uses.
Some of the features I read about sound interesting... without a pressing need, though, I'll happily wait for a more acceptable solution.

Re:Nooooooooo (0)

Anonymous Coward | about 6 months ago | (#46886581)

Yeah, imagine having to choose good ECC crypto instead of the NSA-approved stuff.

http://safecurves.cr.yp.to/

Another political move (-1, Troll)

bluefoxlucid (723572) | about 6 months ago | (#46882945)

Still throwing a tantrum I see. Funny that this has been a long time coming, but it only happens when it's fashionable to bash OpenSSL.

Re:Another political move (1)

sinij (911942) | about 6 months ago | (#46883011)

If your project only needs SSH, having OpenSSL is an overkill.

Re:Another political move (1)

petermgreen (876956) | about 6 months ago | (#46885627)

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:Another political move (1)

rubycodez (864176) | about 6 months ago | (#46883123)

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.

Vetting the replacement libraries? (4, Insightful)

mlts (1038732) | about 6 months ago | (#46882963)

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? (-1, Flamebait)

Anonymous Coward | about 6 months ago | (#46883149)

No worries. Group-sourcing everything and making it open source will take care of any security issues, just like it did with OpenSSL.

Stop asking so many fucking questions, dude. Open source is perfect.

Re:Vetting the replacement libraries? (0)

Anonymous Coward | about 6 months ago | (#46885915)

Open source is perfect.

WTF?

Not by a long shot, but I submit to you, in all seriousness, that it's better than the alternative.

Re:Vetting the replacement libraries? (3, Informative)

Noryungi (70322) | about 6 months ago | (#46884069)

LibreSSL will indeed, by used by OpenSSH.

See here for more details: http://undeadly.org/cgi?action... [undeadly.org]

Re:Vetting the replacement libraries? (5, Informative)

chriscappuccio (80696) | about 6 months ago | (#46884291)

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. (3, Insightful)

sinij (911942) | about 6 months ago | (#46882965)

Get this version of OpenSSH FIPS certified and it will be default industry standard for the next decade.

Re:Good news! Now get it FIPS certified. (1)

Anonymous Coward | about 6 months ago | (#46883155)

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:Good news! Now get it FIPS certified. (1)

kthreadd (1558445) | about 6 months ago | (#46883171)

What's the industry standard of this decade?

Re:Good news! Now get it FIPS certified. (1)

mwvdlee (775178) | about 6 months ago | (#46883239)

We still have six more years to go, so I think either the next standard or the third one after that.

Re:Good news! Now get it FIPS certified. (2)

Noryungi (70322) | about 6 months ago | (#46884087)

Or, as the fortune used to read: The good thing with standards is that there are so many of them to choose from...

Re:Good news! Now get it FIPS certified. (1)

rubycodez (864176) | about 6 months ago | (#46883173)

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 (0)

denis-The-menace (471988) | about 6 months ago | (#46883509)

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:symbolism over substance in the realm of secury (2, Insightful)

Anonymous Coward | about 6 months ago | (#46883721)

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.

Re:symbolism over substance in the realm of secury (1)

fnj (64210) | about 6 months ago | (#46886019)

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 (0)

Anonymous Coward | about 6 months ago | (#46886497)

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.

Re:symbolism over substance in the realm of secury (3, Funny)

theshowmecanuck (703852) | about 6 months ago | (#46886555)

'one party, two faces'

FTFY: 'one party, two feces'

Re:Good news! Now get it FIPS certified. (5, Insightful)

Doug Otto (2821601) | about 6 months ago | (#46883533)

While your points are certainly valid, they do little to mitigate the need for FIPS when dealing with things like FBI CJIS data. Either you're in compliance or they disconnect you. It's sort of like arguing with a TSA agent; it'll make you feel a little better but it won't actually change anything.

Re:Good news! Now get it FIPS certified. (1)

rubycodez (864176) | about 6 months ago | (#46883593)

Large city police departments are already pushing back at FBI for their lagging technical crypto requirements.

Re:Good news! Now get it FIPS certified. (1)

ChunderDownunder (709234) | about 6 months ago | (#46886369)

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. (2, Informative)

Anonymous Coward | about 6 months ago | (#46883385)

You can't certify source code. You can only certify binaries. That makes FIPS certification a challenge for most users and implementers.

Re:Good news! Now get it FIPS certified. (1)

TechyImmigrant (175943) | about 6 months ago | (#46883689)

25519, chacha20 and poly1305 are not FIPSable algorithms.

Re:Good news! Now get it FIPS certified. (1)

Noryungi (70322) | about 6 months ago | (#46884109)

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. (4, Informative)

TechyImmigrant (175943) | about 6 months ago | (#46884211)

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:Good news! Now get it FIPS certified. (1)

Noryungi (70322) | about 6 months ago | (#46884317)

OK, thank you for that information.

Re:Good news! Now get it FIPS certified. (1)

TechyImmigrant (175943) | about 6 months ago | (#46884969)

Apologies for the huge number of typos I managed to fit into that response.

Re:Good news! Now get it FIPS certified. (0)

Anonymous Coward | about 6 months ago | (#46886669)

Correct, since only NSA back-doored encryption schemes are allowed in the FIPS specifications.

Re:Good news! Now get it FIPS certified. (0)

Anonymous Coward | about 6 months ago | (#46883883)

Certified to contain US Gov preferred backdoors?

No thanks.

Cut off an arm and a leg to lose the chains (0)

Anonymous Coward | about 6 months ago | (#46882969)

People need to reinvent the wheel more. It creates diversity.

Compiler option (1)

Anonymous Coward | about 6 months ago | (#46882971)

So, OpenSSH has now a compiler option to disable OpenSSL. OpenSSL had a compiler option to disable heartbleed. Did it help?

Re:Compiler option (1)

kthreadd (1558445) | about 6 months ago | (#46883191)

Yes it did. You were not vulnerable if you have built OpenSSL with the feature disabled.

Re:Compiler option (4, Interesting)

adisakp (705706) | about 6 months ago | (#46883425)

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:Compiler option (1)

kthreadd (1558445) | about 6 months ago | (#46883609)

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 (1)

ConstantineM (965345) | about 6 months ago | (#46883737)

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:OPENSSL_NO_HEARTBEATS (2)

Em Adespoton (792954) | about 6 months ago | (#46883933)

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 is reimplementing it correctly.

Re:OPENSSL_NO_HEARTBEATS (1)

WaffleMonster (969671) | about 6 months ago | (#46884099)

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:OPENSSL_NO_HEARTBEATS (0)

Anonymous Coward | about 6 months ago | (#46885343)

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.

The guy who screwed up the implementation apparently also screwed up the specification with the same amount of missing and vague error handling (lack of error codes, vague explanations, missing limits, etc.) . Not to forget that this feature could be freely accessed by just about anyone as it lacked authentication - leaving the OpenSSL process open to continued anonymous probing for more flaws and possible DoS attacks. 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.

Re:OPENSSL_NO_HEARTBEATS (0)

Anonymous Coward | about 6 months ago | (#46885361)

Although in the DTLS can be trivially implemented within the app rather than transport layer

No RSA? (2)

TechyImmigrant (175943) | about 6 months ago | (#46882983)

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:No RSA? (0)

Anonymous Coward | about 6 months ago | (#46883265)

RSA is a minefield. Just one that we're all gotten complacent about.

Re:No RSA? (0)

Anonymous Coward | about 6 months ago | (#46883287)

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.

Trusty old divide large numbers problem, eh?

Re:No RSA? (1)

ledow (319597) | about 6 months ago | (#46883485)

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:No RSA? (0)

Anonymous Coward | about 6 months ago | (#46885085)

ECC has been around for over 30 years (1985 when it was first publicly discussed, but the NSA knew about it earlier) and it is certified for military usage (Suite B algorithms use ECC and are suitable--nay preferred--for military usage).

You're reciting arguments from like 15 years ago. In the mean time, academia and industry continued to study ECC and decided it's the best thing going.

Re:No RSA? (1)

brynet (3462983) | about 6 months ago | (#46883331)

Support for RSA and (non-EC)DSA key types might be added eventually; even sooner if you sent patches.

Re:No RSA? (1)

TechyImmigrant (175943) | about 6 months ago | (#46883741)

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:No RSA? (0)

Anonymous Coward | about 6 months ago | (#46883349)

It's a minefield that some very experienced and trustworthy people have helpfully cleared a wide path through: http://safecurves.cr.yp.to/

Re:No RSA? (1)

bill_mcgonigle (4333) | about 6 months ago | (#46883491)

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 glibc world, I'd be willing to replace my RSA keys at this point for security-sensitive work.

Thank you, Team OpenSSH.

Re:No RSA? (1)

TechyImmigrant (175943) | about 6 months ago | (#46883555)

>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:No RSA? (0)

Anonymous Coward | about 6 months ago | (#46885345)

OpenSSL's default RSA implementation is constant time.

One reason to keep OpenSSL instead of chucking it entirely is because although the code is ugly and broken in places, it's algorithm implementations have been hammered by researchers mercilessly. (Researchers as a rule suck at writing or auditing code, but are great at finding bugs for which they can write papers for.)

There's a difference between product A, which claims a constant time algorithm, and product B which claims a constant time algorithm and has been through the fire, with deficiencies detected and fixed.

(FWIW, the above statement is not a veiled commentary on DJB's ECC code being added to OpenSSH.)

Re:No RSA? (1)

TechyImmigrant (175943) | about 6 months ago | (#46883669)

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:No RSA? (1)

Anonymous Coward | about 6 months ago | (#46884591)

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, gives me a third integer. That's where the elliptic curve comes in. One also has to define negation. Details ... This is why ECC as implemented by curve 25519 is secure, because p is so large, and no one can crack the discrete logarithm problem [wikipedia.org] . The bottom line is that all known attacks on ECC are extremely expensive computationally. The best known attack needs ~ 2^140 operations. You can't brute force that in the lifetime of the universe using gigawatts of computation. 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.

Re:No RSA? (1)

TechyImmigrant (175943) | about 6 months ago | (#46885119)

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 mass market products is not just a technical problem. It involves politics, risk management and paranoid lawyers. ECC wins on the technical bit and screws the pooch on the other three. I'm not going to let those issues get in the way.

Saving a few bits on the stored key is not a good tradeoff with having to deal with all the people who don't have the technical knowledge to know what's right or wrong with ECC, but they've sure heard lots of FUD before.

Lots of algorithms are adequate. The challenge these days battling complexity in communication and computing standards that lead to vulnerable implementations.

Re:No RSA? (1)

cryptizard (2629853) | about 6 months ago | (#46885233)

The NSA actually recommends ECC exclusively for public key encryption as part of its suite B, and not RSA. Make of that what you will.

Re:No RSA? (1)

blueg3 (192743) | about 6 months ago | (#46885553)

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 limited contexts (very limited). Public-space crypto experts are getting uncomfortable with the security of RSA as a result. The NSA, besides spying on people, is *also* tasked with helping US interests maintain computer and signals security. The NSA has a lot of good mathematicians and a lot of advanced computing resources. The NSA now advocates that nobody that is storing data that the government considers valuable use RSA or Diffie-Hellman any more. What do you suppose that might all mean?

It may be a case of "you're damned if you do, you're damned if you don't". But using RSA seems to be a lot more damning.

How about reducing problems (2)

cheesybagel (670288) | about 6 months ago | (#46883073)

Just create a crypto library and make OpenSSH and LibreSSL depend on that instead of duplicating hard to debug code everywhere.

Re:How about reducing problems (1)

mlts (1038732) | about 6 months ago | (#46883109)

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:How about reducing problems (0)

Anonymous Coward | about 6 months ago | (#46883413)

AES isn't a replacement for RSA, they perform very different functions.

Re:How about reducing problems (1)

mlts (1038732) | about 6 months ago | (#46883557)

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:How about reducing problems (2)

TechyImmigrant (175943) | about 6 months ago | (#46883885)

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.

Very cool! (1)

Luke Morrison (3637845) | about 6 months ago | (#46883433)

Small is better!

Not a bad thing, but not that important (1)

swillden (191260) | about 6 months ago | (#46883479)

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.

Re:Not a bad thing, but not that important (2)

swillden (191260) | about 6 months ago | (#46883489)

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 (5, Interesting)

TechyImmigrant (175943) | about 6 months ago | (#46883507)

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]);
}

Re:AES-CTR (0)

Anonymous Coward | about 6 months ago | (#46884049)

Score:5, Interesting ?

Did you take the time to compile this crap ?

Re:AES-CTR (1)

TechyImmigrant (175943) | about 6 months ago | (#46884441)

That crap is years old and has been in many products. You'll find it in linux drivers.

Re:AES-CTR (0)

Anonymous Coward | about 6 months ago | (#46884161)

Since when has Slashdot been about security, maths, code and such nerdy things? I dunno... is this like some "News for Nerds" site... where's all the lolcats and funny stories about badgers? Hm? Hm?

Rock the boat! (1)

burni2 (1643061) | about 6 months ago | (#46885169)

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... [wikipedia.org]

Re:AES-CTR (1)

cryptizard (2629853) | about 6 months ago | (#46885283)

Why go through all that trouble when a PRP is indistinguishable from a PRF except with negligible probability... If you find two inputs that map to the same block with a PRF that is equivalent to just guessing the encryption key.

Re:AES-CTR (2)

TechyImmigrant (175943) | about 6 months ago | (#46885443)

Because when you invoke AES with the same key many times, you leave yourself more vulnerable to side channel and fault injection attacks.

Re:AES-CTR (0)

Anonymous Coward | about 6 months ago | (#46886119)

if you reuse the key for stream cipher then you're fucked anyhow

Re:AES-CTR (0)

Anonymous Coward | about 6 months ago | (#46886607)

Yeah, there is absolutely no need. No real bias has ever been shown.

Re:AES-CTR (1)

dmiller (581) | about 6 months ago | (#46886615)

AES-CTR being based on a permutation rather than a true PRF might matter if SSH used all the counter values, but SSH rekeys every 2^32 blocks at most - a tiny fraction of the 2^128 possible counters.

Using Elliptic Curves? (0)

Anonymous Coward | about 6 months ago | (#46884081)

With magic numbers provided by the NSA?

Re:Using Elliptic Curves? (1)

TechyImmigrant (175943) | about 6 months ago | (#46884431)

That's the Dual-EC-DRBG that has magic numbers.
The 25519 spec describes the source of all the constants.

Where is arcfour? (1)

nbritton (823086) | about 6 months ago | (#46884449)

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:Where is arcfour? (2)

blueg3 (192743) | about 6 months ago | (#46885567)

Dead. Where it belongs.

Re:Where is arcfour? (0)

Anonymous Coward | about 6 months ago | (#46885601)

ChaCha-20 is faster than RC4. Approaching 4-times faster for highly optimized implementations, but in general just plain faster. Unlike RC4, ChaCha-20 is parallelizable.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?