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!

TLS 1.3 Draft Prepares to Drop Static RSA Key Exchange

Unknown Lamer posted about 6 months ago | from the forward-secrecy-for-all dept.

Encryption 51

msm1267 (2804139) writes with a bit of news from last week that seems to have slipped under the radar. The IETF TLS working group has reached consensus on dropping static RSA cipher suites from TLS 1.3, instead requiring the use of Diffie-Hellman Exchange (or the faster ellipitic curve variant). Static DH and not just ephemeral DH key exchange will be supported, so not all connections will have forward secrecy. The consensus is subject to change before the final TLS 1.3 specification is released, and there are still details to be worked out. The changes to the draft are pending as a git pull request.

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

Temporary RSA keys? (5, Insightful)

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

I've wondered why there isn't a protocol similar to what was used in SSH 1.x, where every x amount of time (default was ten minutes), there was a set of RSA keys generated and kept in memory, used for transactions (and signed with the permanent set of keys), then tossed.

In theory, PFS should be the core of TLS... negotiate the protocol, use DH or the elliptic curve variant to hammer out a session key, re-negotiate the session key every so often, and in any case, toss the session key for good. Having a temporary set of RSA keys similar to SSH 1.x provides protection because it make the permanent host keys essentially signing keys only, not used for encryption, so less data would be encrypted by those keys.

Re:Temporary RSA keys? (0)

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

Basically the entire SSL system is a collection of things that everybody thinks are done differently than they actually are. Lack of perfect forward secrecy in common use is just one such thing. How many iterations of "but now the CAs really check" did we have? Do you think they really check now? SSL even had a name change, the hallmark of all things so broken that they can not clear their old name and need a new one to look respectable again. Now what? With all that has happened recently, NSA and Heartbleed, these jokers still can't agree on requiring perfect forward secrecy? The saga of fail continues...

Re:Temporary RSA keys? (0)

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

Doesn't matter, the continued use of XP+IE means that nobody can leave SSLv3.0 anyway, at least without cryptic error messages telling your user that your site is broken.

Re:Temporary RSA keys? (1)

Bengie (1121981) | about 6 months ago | (#46943613)

You think that's bad, we still have a few Win98+FF1 agent strings coming through.

Re:Temporary RSA keys? (1)

viperidaenz (2515578) | about 6 months ago | (#46943827)

That could be someone changing their UA string to confuse you.

My old Android phone had CM7 installed and the browser let you select one of about 10 UA strings, with the intention of not being redirected to only-works-for-iphones-but-we'll-redirect-all-mobile-browsers-to-this-shitty-cut-down-version-that-lacks-content websites.

Re:Temporary RSA keys? (2)

goddidit (988396) | about 6 months ago | (#46941851)

Generating RSA keys is more costly than, for example, ECDH keys. Checks for primality for the p and q, are needed for it to be secure for RSA. In my understangin, any big enough integer is a valid DH private key.

Static RSA would be nice for certain applications, since it is computationally cheaper to do for the client. Also, with DANE for instance, the same primitives can be used to check signatures. Yet, RSA might be costly in the future keylengths. For instance, some say that 256-bit symmetric keys are equivalent with 15k RSA keys.

Re:Temporary RSA keys? (1)

Bengie (1121981) | about 6 months ago | (#46944131)

It's been a while, but I think the break even point for computational costs between RSA and ECC is something around 1500bit RSA and 200bit ECC, but the 200bit ECC is much stronger. ECC's computation grows closer to linear while RSA is exponential. With 2048bit RSA being standard now, ECC is now cheaper, minus hardware acceleration reasons.

Perfect Forward Secrecy implementations (0)

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

For the crypto-noob, where is PFS in relation to this update?

Re:Perfect Forward Secrecy implementations (1)

chill (34294) | about 6 months ago | (#46941129)

In the link in the third sentence of the summary titled "forward secrecy". Is this a trick question?

wat (0)

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

Can someone give me an EL5 of this story?

Explained to a single digit year old (2)

tepples (727027) | about 6 months ago | (#46941863)

There are some things you want to share, and there are some things you don't want to share, which are called "private". And there are people in other countries who want to hurt you, who are called "terrorists". There's a part of the government called the NSA that looks at other people's private things in order to stop terrorists from hurting you. But some people don't like strange people looking at their private things.

Sometimes you want to share your private things with other people you trust. One of the ways to make sure nobody else can see your private things is to use encryption. Encryption does complicated math problems on your private things. If something is encrypted, only the person you're sharing it with can see it because other people watching your Internet connection won't be able to solve the math problems. This involves another math problem called a "key exchange". A piece of software on your computer called a "crypto library" does encryption and key exchanges.

What happened here is that some people think RSA, a company that makes key exchanges, was working with the NSA to help it look at your private things. And someone found a different solution to RSA's key exchange. That's why people who make a popular crypto library want to stop using RSA's key exchange.

Re:Explained to a single digit year old (2, Informative)

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

Nice and simple language, but factually all wrong. This has nothing to do with the NSA or the RSA.

The RSA in TFA is a cryptographic primitive. It should not be confused with the company RSA Security LLC, though both are named after the cryptographers Ron Rivest, Adi Shamir, and Len Adleman.

RSA is not considered broken or backdoored, but has some disadvantages compared to elliptic curve based alternatives, including lack of forward secrecy, and long key lengths at high security levels.

Re:Explained to a single digit year old (1)

tepples (727027) | about 6 months ago | (#46942869)

The RSA in TFA is a cryptographic primitive. It should not be confused with the company RSA Security LLC

That and the fact that RSA the primitive was first published by RSA the company. But I'll grant that I had misunderstood things.

Re:Explained to a single digit year old (1)

Kjella (173770) | about 6 months ago | (#46943177)

That and the fact that RSA the primitive was first published by RSA the company. But I'll grant that I had misunderstood things.

No, the cipher predates the company by 5 years. But same people, obviously to provide services around the cipher they build.

Re:Explained to a single digit year old (1)

TubeSteak (669689) | about 6 months ago | (#46944797)

And there are people in other countries who want to hurt you, who are called "terrorists". There's a part of the government called the NSA that looks at other people's private things in order to stop terrorists from hurting you.

That's what the NSA wanted us to believe before Snowden's leaked documents showed us otherwise.

So unless you're willing to argue that the Chancellor of Germany is a terrorist, please stop repeating the Party line.

Re:Explained to a single digit year old (0)

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

I'm German and mildly terrified of Angela Merkel. She just might qualify.

Re:Explained to a single digit year old (0)

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

You mean, she is not a terrorist proper, but may be a terririst (terrifist? terrifyist?) ?

Re:Explained to a single digit year old (0)

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

Encryption does complicated math problems on your private things

Does it hurts me when it does that to my private things?

Identity theft (1)

tepples (727027) | about 5 months ago | (#46951651)

Does it hurts me when it does that to my private things?

Some people can misuse your private things to take your money or to lie to other people that you did things that you never really did. This misuse is called "identity theft". And that's one thing that encryption can help prevent when used in the right way.

Re:wat (2)

viperidaenz (2515578) | about 6 months ago | (#46943851)

Oh my god, where are your parents?

OpenSSL gets patch for another years old flaw (2, Informative)

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

In other news [eweek.com] , OpenSSL gets a 4-year-old flaw patched. The catch here is that the bug was not only 4 years in the codebase, but it was publicly reported (CVE-2010-5298 [nist.gov] ) for 4 years, without no one taking the responsibility to fix it.

OpenBSD developer Ted Unangst made a detailed report [tedunangst.com] of the bug. It's not as severe as Heartbleed, but still allows remote attackers to inject data across sessions or cause a denial of service (use-after-free and parsing error) via an SSL connection in a multithreaded environment.

Re:OpenSSL gets patch for another years old flaw (2)

just_another_sean (919159) | about 6 months ago | (#46941189)

Yeah, I've been trying to keep up [opensslrampage.org] . It's heavy stuff and a little over my head sometimes but never the less very interesting (and sometimes very amusing).

Re:OpenSSL gets patch for another years old flaw (1)

postbigbang (761081) | about 6 months ago | (#46941471)

It's also pretty shocking that such madness even exists, save that open source can be like government, fixing only the things that people really bitch about, rather than infrastructure components that are decades old, and older.

If people paid attention to core components like they did the Linux kernel perhaps there'd be a lot of noise, but a lot of better code.

Yo: Linus-- you listening? Kernel ain't crap without other components that work and are rationally safe. Cut loose a few of your homies to do some maintenance-- the bridges are collapsing.

Obviously not familar with how things work. (0)

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

The people that work on the kernel are not necessarily the people you want working on encryption.

To understand the encryption requires a LOT of mathematical analysis.... and there aren't enough of them to go around. The best paid ones work for the NSA.

In addition, the kernel programmers are VOLUNTEERS.

Re:Obviously not familar with how things work. (1)

postbigbang (761081) | about 6 months ago | (#46942005)

I realize these are volunteers. I'm exactly this kind of volunteer, but in a different sub-discipline. I'm booked, and understand how others have their own motivations. Yet strong classical coders are good in most endeavors, and this is one (the entire encryption chain) that needs serious review, as the others are worthless without cogent and secure code.

Want to actually be secure (0)

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

Exchange in a secure manner (in person) a private one time use page with truly random data. 2 TB hard drive with captured static noise. XOR your data with this random data at each end. Then the NSA has to come to your place with black masks and thumb screws to decrypt your communications.
But in the end who cares. Let the royals watch their peasants.

Re:Want to actually be secure (1)

weilawei (897823) | about 6 months ago | (#46946349)

That 2 TB of key material has to be stored somewhere, and can't ever be reused. Is your data storage coercion-proof? Also, how much do you like sneaker-net? At that point, you might be better off not committing things to paper.

Static DH is not better than Static RSA (1)

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

Static DH is not better than Static RSA

PFS is nice and all. But why the hate for RSA? It's a well understood algorithm.

What the TLS designers need to think about is how to reduce the options to one well understood choice. So the complexity of ciphersuite negoitation, rekeying and all the other absurd complexity can be removed.

TLS will not be fixed. It will be replaced.

Re:Static DH is not better than Static RSA (0)

PeeAitchPee (712652) | about 6 months ago | (#46942473)

But why the hate for RSA? It's a well understood algorithm.

Maybe because RSA has proven time and again that they can't be trusted [reuters.com] ?

Re:Static DH is not better than Static RSA (2)

bytesex (112972) | about 6 months ago | (#46942505)

Are you purposely, or ignorantly, confusing RSA, the company, with RSA, the assymetric cipher suite based on primes?

Re:Static DH is not better than Static RSA (1)

PeeAitchPee (712652) | about 6 months ago | (#46942593)

Got it . . . easy for someone who doesn't work with crypto every day to get confused, especially as RSA the company has developed many security-related bits of infrastructure. In fact, as far as I can tell, there's no relationship between RSA (the company) [wikipedia.org] and RSA (the crypto suite) [wikipedia.org] . My bad.

Re:Static DH is not better than Static RSA (1)

Kjella (173770) | about 6 months ago | (#46942849)

In fact, as far as I can tell, there's no relationship between RSA (the company) and RSA (the crypto suite). My bad.

Well, none except the RSA in the company and the cipher is the same. Or did you miss this line?

Ron Rivest, Adi Shamir and Leonard Adleman, who developed the RSA encryption algorithm in 1977, founded RSA Data Security in 1982

Re:Static DH is not better than Static RSA (1)

PeeAitchPee (712652) | about 6 months ago | (#46942997)

Nope -- I didn't miss it. 1982 was a long time ago, and RSA (the company) bears little resemblance today to RSA (the company) of 1982. In any case, was RSA (the company) involved in the development / imporvements / other iterative activities related to RSA (the crypto suite in question) or not, especially recently? Because if that's the case, my original point stands, as there's plenty of evidence that RSA (the company) has been complicit in NSA's efforts to backdoor and other undermine / weaken components which they (RSA the company) had developed.

Re:Static DH is not better than Static RSA (1)

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

Maybe because RSA has proven time and again that they

In this context by "RSA" we're talking about use of prime numbers as basis for a public key cryptosystem rather than the company "RSA".

http://en.wikipedia.org/wiki/R... [wikipedia.org]

Re:Static DH is not better than Static RSA (1)

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

What the TLS designers need to think about is how to reduce the options to one well understood choice.

Putting all of your eggs in one basket yields global disaster with unacceptable lag times to recovery when dropped.

It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options.

So the complexity of ciphersuite negoitation, rekeying and all the other absurd complexity can be removed. TLS will not be fixed. It will be replaced.

KISS is great and all but it falls apart when you go that one step further and try to oversimplify.

Anyone can look at a specific problem and provide a *relatively* simple custom crypto solution to solve that one problem. I'm not so sure a world with proliferation of fragmented technologies is necessarily better than a single albeit more complex than you need framework. Perhaps for some it is... I don't know.

Re:Static DH is not better than Static RSA (1)

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

I disagree. There has been far more failure in SSL/TLS protocols and implementation from complexity in the handshakes than there has been from the basic crypto being broken (which it isn't).

Make a really good basket and put your eggs in it.

>KISS is great and all but it falls apart when you go that one step further and try to oversimplify.

Not in crypto. Complexity is crypto is nothing but fail.

>Anyone can look at a specific problem and provide a *relatively* simple custom crypto solution to solve that one problem. I'm not so sure a world with proliferation of fragmented technologies is necessarily better than a single albeit more complex than you need framework. Perhaps for some it is... I don't know.

After banging my head on this for a decade I've fallen on the side of lots of little, simple solutions for lots of specific security contexts. No one can design a TLS like thing and get it right.

Re:Static DH is not better than Static RSA (0)

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

There have been several recent breaches in SSL/TLS that were mitigated by the ability to negotiate ciphers.

When the BEAST attack was published, the quick fix was to configure clients and servers to prefer stream ciphers like RC4.

Then when RC4 was shown to be broken (oops!), the fix was to prefer block ciphers again - and hope that most clients had implemented the more permanent BEAST mitigations by then.

Most of the ciphers supported in SSL 3 have been broken, yet the protocol is still supported almost everywhere. It's too risky to back just one cryptographic horse when they can suddenly and catastrophically fail for reasons beyond your control.

Cipher agility allows things like Google recently adding ChaCha20-Poly1305 [blogspot.com] support to Chrome. A great cipher for mobile devices.

Re:Static DH is not better than Static RSA (1)

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

And yet, the underlying crypto was sound. The composition was broken. If they had specified a proper random IV and not allowed alternatives, beast could not have happened.

The weight of TLS made the details of the CBC implementation appear minor. But in fact getting that right is a primary task.

If there was less work on the bucket full of protocol, perhaps there would have been time for people to listen to the crypto guys when they say your IV must be random. If CBC was the only privacy mode, you can be sure that someone would have commented on the IV issue because that is pretty much the only requirement on external inputs to CBC.

Re:Static DH is not better than Static RSA (0)

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

The underlying crypto wasn't sound for RC2, RC4 or DES.

It's easy with hindsight to ask why they didn't just use the cipher that was going to stay secure for 20 years, but at the time they could just as easily have chosen RC4 as triple DES.

You don't know which ciphers are going to break, and it takes ages for everyone to update to newer versions. Eliding cipher agility in that environment isn't an option.

Re:Static DH is not better than Static RSA (1)

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

But to replace RC4, new software had to be written and released. Interworking with old implementations is still broken today. TLS is a life raft for broken crypto.

Given that you know new software has to be released just tie one algorithm for each purpose to one version.

--> HI_MY_MAX_VERSION_IS_X
-- HI_MY_MAX_VERSION_IS_Y
Chosen cipher == Lookup_cipher(min(X,Y))
Refuse or allow based on whether we are willing to do min(X,Y).
MAC the whole exchange, continue.

This looks like ciphersuite negotiation, but it isn't. It's protocol version negotiation which happens anyway.

As has been pointed out in many forums, the problem with ciphersuites is not just getting new ciphers in. It's getting old ciphers out. Getting old crypto out is just one of TLS's many failings.

Re:Static DH is not better than Static RSA (1)

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

It's notable that in the current draft they still don't get it right.
IV
            The Initialization Vector (IV) SHOULD be chosen at random, and
            MUST be unpredictable. Note that in versions of TLS prior to 1.1,
            there was no IV field, and the last ciphertext block of the
            previous record (the "CBC residue") was used as the IV. This was
            changed to prevent the attacks described in [CBCATT]. For block
            ciphers, the IV length is of length
            SecurityParameters.record_iv_length, which is equal to the
            SecurityParameters.block_size.

The implementer is left to interpret 'random' and 'unpredictable' in ways that are useful for an effective cryptographic outcome.
Unpredictable to who? Certainly not to the generating end if a CSPRNG is being used.

What kind of random? There are many definitions of random that don't fall into the cryptographically useful set.

We know much more about randomness than we did 5 years ago. It doesn't seem like the TLS authors have really kept up.

I'm not interested in helping TLS by fixing their spec. I'm only interested in destroying it and replacing it with something sane.

Re:Static DH is not better than Static RSA (1)

TXISDude (1171607) | about 6 months ago | (#46942991)

"It is not the designers responsibility. Rather education campaigns to assist application developer and operator community in selecting appropriate cipher suites and or more work in security stacks to provide generally applicable options."

This mentality has led to so many errors - lest I say many C functions, that routinely result in fail because no one did bounds checking . . . We will always have poor developers, so we need to use standards and tech to help them get it right. Saying it is the developer's responsibilities to get it right is fantasyland, and to everyone who has been there they know it is never as great as they thought it would be.

Re:Static DH is not better than Static RSA (1)

weilawei (897823) | about 6 months ago | (#46946429)

The temptation to optimize for speed/memory usage over producing correct code is like will'o'the'wisps for many developers. If you develop code for a hostile environment (the default assumption for crypto) it should be assumed that any inputs will be abused.

Further, in a hostile environment, developers also need to assume that they won't have anticipated every possible way to extract information from a process. Do the simplest thing that will always work, within the limits you can predict. Then fix the bugs as you find them, because you WILL have some. Hopefully, you have a qualified set of eyes willing to review your code.

For example, timing attacks are pervasive in cryptography, and incredibly easy to enable without very thorough consideration of possible paths. Often, with higher-level languages, you have little opportunity to mitigate these issues. You check bounds because it's the low-hanging fruit for an attacker, not because it will provide absolute security. It merely raises the bar for an attacker. Crypto is often subject to attacks enabled via multiple layers of abstraction (all the way down to turtles) which obscure potential problem areas.

Re:Static DH is not better than Static RSA (1)

VortexCortex (1117377) | about 6 months ago | (#46944877)

But why the hate for RSA?

Because elliptic curve is less expensive: Providing the same degree of difficulty for far less bits, or more computational difficulty for the same bits. Takes less CPU to compute, so lighter weight makes it more useful. Eg: In my alternate distributed "toy" OS's PKI system there are "permission spaces". Every agent can be granted a permission, and can grant permissions to other agents, perhaps reducing the permissions possible the agent can grant to the next, including the permission to grant certain permissions to others. Instead of cert revocation headaches I can simply require re-keying of entire distributed trust graphs in real time by limiting the validity to short intervals; I can do this because of the efficiency of elliptic curve cryptography. When I drop in RSA or DH replacements the system is brought to its knees unless I reduce the encryption strength to easily crackable levels.

Really though, the IETF should be fired. They've never been working with our best interests in mind, their design by committee bullshit stinks of pet project pissing contests. The main problem remains that any CA can generate certs for any domain with or without the domain owner's permission. As long as this remains true the entire TLS system will merely be a collection of single points of failure, and compromise of any one of them takes down the whole system. We shouldn't have to trust EVERY CA in order for the system to remain intact, but we do, and that's dumb. Decentralized approaches to name space mapping exist, and can be applied to identity graphs.

The Internet was beautiful, but the web built atop it is trash. Time to start over. This time let's consider that RF exists, and that my neighbor might as well pull that youtube vid I just watched from me if possible, hell, they may even download the part I'm watching from the peer I'm downloading from while also downloading the part I already watched from me. One to many relationships exist simply the physical world that are hard or impossible in the current point to point networked world. Anyone who thinks a new system can't come along and replace everything never used BBSs, or cell phones for that matter.

The web is dying. Long live the network.

Mandating security (1)

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

I think it is a mistake for IETF to make value judgments about mandating a lowest acceptable level of security. Not everyone is faced with the same problems or places the same value on specific aspects of security.

Ability to decode encrypted sessions after the fact could in some instances offer more value than risks associated with retroactive effects of key compromise. TLS after all has ability to negotiate ciphers offering no encryption at all while still offering integrity protection for data.

If your using TLS for an industrial control application perhaps there is no value in keeping commands issued secret yet there is extreme value in maintaining integrity of data so harmful commands can't be injected by an attacker. In this scenario forward secrecy has no value, and you lose the ability to retroactively validate data stream with ephemeral keys.

For troubleshooting, auditing and political considerations (like it or not leakage prevention is a multi-billion dollar industry) an organization may deem properties of forward secrecy to be more of a liability than an asset.

Also session tickets and ephemeral keys don't mix.

Obviously you want to provide the strongest generally applicable level of security by default in any specification or implementation however if you want to provide a technological solution *everyone* can use it by necessity needs to support full range of tradeoffs where reasonable. In this case I am not hearing the "reasonable" argument for deletion of these suites.

Reasons Joe cites for removal sound like typical IETF jargon used to provide technical cover for political decisions.

lack of PFS

by identity/choice

pre-master secret contributed only by the client

No, this is an independently addressable (non)issue.

and the general weakening of RSA over time

If RSA is weak then using RSA at all to impart trust upon ephemeral keys is a receipt for disaster. This reduces to the general argument for PFS which everyone should and is free and encouraged to use.

It would make the security analysis simpler

There must be what hundreds of cipher suites by now.. seriously... analyze the ones you see value in using and disable the rest. This makes as much sense as telling the Russians you are deleting suites with *gost* in them or Japanese *camilla* simply because they would be easier to analyze.

Re:Mandating security (1)

Kjella (173770) | about 6 months ago | (#46943125)

TLS is supposed to provide point-to-point security, if you want the information to also go somewhere else then send it there. If you don't trust the starting point then have the ending point do it. So your industrial control system sends commands X to machinery Y, machinery Y forwards it to logger Z before executing the command. Or have the logger be an intentional MITM. While the problems are genuine I feel your solutions create complications in all the wrong places.

Re:Mandating security (0)

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

You're defining "security" to necessarily include "privacy". The original poster is arguing that in some circumstances it only include "integrity", and further that "privacy" may be undesirable.

If you think privacy is the only concern of TLS you should be arguing to have the wasteful and potentially dangerous integrity options removed from the standard, and isolated in their own specification and software. If you're arguing that the two concepts are only useful together there are dozens of examples where that's clearly not true, probably including some you use every day -- like signed software packages.

Re:Mandating security (0)

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

There must be what hundreds of cipher suites by now.. seriously... analyze the ones you see value in using and disable the rest. This makes as much sense as telling the Russians you are deleting suites with *gost* in them or Japanese *camilla* simply because they would be easier to analyze.

That's different. Encryption ciphers have a pretty standard interface and can be plugged in modularly by the dozens.

Key exchange protocols need more customization, and extend the protocol at its most vulnerable spot, before both parties have the keys they need to communicate securely.

Re:Mandating security (1)

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

That's different. Encryption ciphers have a pretty standard interface and can be plugged in modularly by the dozens.

This interpretation was not intent. Term "cipher suite" rather than "cipher" was used intentionally to include combinations of *all* parameters. I could have just as easily said *SRP*

Key exchange protocols need more customization, and extend the protocol at its most vulnerable spot, before both parties have the keys they need to communicate securely.

Negotiation parameters are checked retroactively after session establishment regardless. Peers would have to be configured to allow a cipher suite so broken as to be compromised in real-time during TLS handshake. If RSA could be compromised in this way it is hard to imagine a scenario where binding of trust from RSA to ephemeral key could fair any better.

The hate for RSA (1)

bytesex (112972) | about 6 months ago | (#46942541)

is a bit *too* trendy these days. The NSA should be about five - ten years away from breaking it. If you have secrets that will be worthless by then, then by all means, use it.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?