Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algorithm Agility?

tbray.org

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Algorithm Agility?

#11

Post by upofadown »

RcouF1uZ4gsC wrote: post #7

> should developers just blast the key-bits into base64 and ship that? I would argue given the key lengths of ed25519, not even to do base64, but just do hex encoding. Sure it is a little longer, but in return you get much simpler encoding and decoding, no worries about flavors of base64 or padding. In addition, hex encoding is much easier to verbally communicate to someone versus base64. In a security context, I thi…

Split the difference with base 32? More efficient than hex, you can leave out the 4 easiest letters to confuse with digits and no upper/lower case problem.

Verbal communication is a problem with any system that uses letters. In hex for example; 3, B, C, D and E all sound very much the same.

Re: Algorithm Agility?

#12

Post by sneak »

forgotmypw17 wrote: post #5
tptacek wrote: post #2

Algorithm agility is bad. You see it happening at the beginning of every TLS session; what you don't see are the long trail of vulnerabilities that have resulted from TLS's overly complicated handshake, and, worse, the essentially nonexistent vulnerabilities algorithm agility has mitigated over TLS's lifetime; in general, when TLS constructions have failed, they've failed in the joinery (block cipher modes, MAC arran…

I disagree with locking out old versions. It's a huge problem with older devices trying to access the web via SSL. I think it is important to consider device longevity and also the possibility of the user not being able to upgrade their software. Security is important, but it is not everything. There is also accessibility and compatibility to consider. It's why I still test my websites with Netscape 3.x and keep http…

Postel's law has been deprecated.

Re: Algorithm Agility?

#13

Post by skybrian »

I'm not a any kind of crypto expert, but I'm wondering if this looks like a config file? Let's say you have a JSON file that has one field, which is the key, base64-encoded.

Maybe you won't change the algorithm, but still want to leave room to add another config parameter. The file format is obvious in a text editor and it's easy to add more stuff.

Re: Algorithm Agility?

#14

Post by RcouF1uZ4gsC »

upofadown wrote: post #11
RcouF1uZ4gsC wrote: post #7

> should developers just blast the key-bits into base64 and ship that? I would argue given the key lengths of ed25519, not even to do base64, but just do hex encoding. Sure it is a little longer, but in return you get much simpler encoding and decoding, no worries about flavors of base64 or padding. In addition, hex encoding is much easier to verbally communicate to someone versus base64. In a security context, I thi…

Split the difference with base 32? More efficient than hex, you can leave out the 4 easiest letters to confuse with digits and no upper/lower case problem. Verbal communication is a problem with any system that uses letters. In hex for example; 3, B, C, D and E all sound very much the same.

> In hex for example; 3, B, C, D and E all sound very much the same.

We have a standard way of dealing with that in the form the NATO phonetic alphabet.

So 3BCDE would be “Tree Bravo Charlie Delta Echo”

Re: Algorithm Agility?

#15

Post by tatersolid »

upofadown wrote: post #6

If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.

A lot of research went in to Curve25519; multiple decades of ECC academic investigation created a set of criteria for safety:

See https://safecurves.cr.yp.to/

Re: Algorithm Agility?

#16

Post by MaxBarraclough »

sneak wrote: post #12
forgotmypw17 wrote: post #5

Earlier quoted context omitted.

I disagree with locking out old versions. It's a huge problem with older devices trying to access the web via SSL. I think it is important to consider device longevity and also the possibility of the user not being able to upgrade their software. Security is important, but it is not everything. There is also accessibility and compatibility to consider. It's why I still test my websites with Netscape 3.x and keep http…

Postel's law has been deprecated.

Postel's Law never sat quite right with me.

> Be conservative in what you send, be liberal in what you accept.

The first half makes good sense. You should make efforts to ensure your program is producing well-formed output. That's just a statement of software quality.

The second half is dependent on the problem domain. A web browser should do its best to cope with malformed input, sure. An Ada compiler should not, as an important part of its job is to reject erroneous inputs. Similarly, part of the value of XML schemas is to (at least partially) automate the process of detecting invalid data, perhaps so that bad requests can be rejected.

edit Turns out others have spent more time thinking about this than I have: https://en.wikipedia.org/wiki/Robustness_principle#Criticism

Re: Algorithm Agility?

#17

Post by forgotmypw17 »

slaymaker1907 wrote: post #9
forgotmypw17 wrote: post #5

Earlier quoted context omitted.

I disagree with locking out old versions. It's a huge problem with older devices trying to access the web via SSL. I think it is important to consider device longevity and also the possibility of the user not being able to upgrade their software. Security is important, but it is not everything. There is also accessibility and compatibility to consider. It's why I still test my websites with Netscape 3.x and keep http…

Can Netscape even work on modern Windows?

Not sure, but it works great on modern Wine.

Re: Algorithm Agility?

#18

Post by upofadown »

tatersolid wrote: post #15
upofadown wrote: post #6

If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.

A lot of research went in to Curve25519; multiple decades of ECC academic investigation created a set of criteria for safety: See https://safecurves.cr.yp.to/

Curve25519 has only been around for something like 10 years. A catastrophic attack on it would presumably involve new ideas specific to that particular or class of curves.

Otherwise any completely new system would have to be considered secure, as it would not suffer from any of the issues of any of the older systems. My understanding is that new elliptic curves can have entirely new characteristics not shared by older curves.

Re: Algorithm Agility?

#19

Post by tatersolid »

upofadown wrote: post #18
tatersolid wrote: post #15

Earlier quoted context omitted.

A lot of research went in to Curve25519; multiple decades of ECC academic investigation created a set of criteria for safety: See https://safecurves.cr.yp.to/

Curve25519 has only been around for something like 10 years. A catastrophic attack on it would presumably involve new ideas specific to that particular or class of curves. Otherwise any completely new system would have to be considered secure, as it would not suffer from any of the issues of any of the older systems. My understanding is that new elliptic curves can have entirely new characteristics not shared by olde…

Curve25519 was introduced in 2005 and seems to have had rapid uptake in academia due to the reputation of one of the authors (djb).

So Curve25519 has had 16 years of widespread academic scrutiny. That’s “battle-tested” by modern cryptographic standards.

Re: Algorithm Agility?

#20

Post by tptacek »

upofadown wrote: post #6

If someone suddenly breaks the stuff based on the 25519 curve there are going to be a lot of very unhappy people. I am still waiting for an explanation of why this particular curve is immune to such a breakthrough.

Nobody thinks it is. Curve25519 being invincible is not the premise behind the shift away from "agility".
Post reply on HN