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

OpenSSH 8.2

lists.mindrot.org

Post reply on HN
Print view View original

11–20 of 61 posts

Re: OpenSSH 8.2

#11

Post by mkj »

zimmerfrei wrote: post #9
RL_Quine wrote: post #4

Earlier quoted context omitted.

Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.

You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA…

The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)

Re: OpenSSH 8.2

#12

Post by aaronmdjones »

mongol wrote: post #5
beefhash wrote: post #2

Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

What does chosen-prefix mean?

It means that you can influence the result by controlling the first part of the input. In other words, you can find an x such that H(x) == H(y) (for x != y) if you get to control the beginning bytes of x and know (or control) the beginning bytes of y.

Re: OpenSSH 8.2

#13

Post by tialaramex »

mongol wrote: post #5
beefhash wrote: post #2

Notably from the changelog: It is now possible[1] to perform chosen-prefix attacks against the SHA-1 algorithm for less than USD$50K. For this reason, we will be disabling the "ssh-rsa" public key signature algorithm by default in a near-future release.

What does chosen-prefix mean?

Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster,"

The attack will calculate suffixes for these two documents such that both documents have the same hash result.

This means the attacker can then show some people a document about Donald, and others the one about Steve and if they rely on the same hash to validate that they're the same document they'd be fooled.

Digital certificates are the most prominent way computers deliberately depend on this assumption which a collision attack makes untrustworthy.

Re: OpenSSH 8.2

#14

Post by tialaramex »

aaronmdjones wrote: post #12
mongol wrote: post #5

Earlier quoted context omitted.

What does chosen-prefix mean?

It means that you can influence the result by controlling the first part of the input. In other words, you can find an x such that H(x) == H(y) (for x != y) if you get to control the beginning bytes of x and know (or control) the beginning bytes of y.

Nope. That's a second pre-image attack.

Re: OpenSSH 8.2

#15

Post by tialaramex »

mkj wrote: post #11
zimmerfrei wrote: post #9

Earlier quoted context omitted.

You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA…

The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)

Indeed, and so to actually use this $50k attack on SSH you'd need to somehow arrange for your target to pick random numbers you expected so that your attack works. But for clarity, OpenSSH isn't saying this can be used against SSH today - the deprecation is because we should abandon broken hashes before they actually cause us harm, not wait until after. Don't Walk Past.

Re: OpenSSH 8.2

#16

Post by _pmf_ »

tialaramex wrote: post #13
mongol wrote: post #5

Earlier quoted context omitted.

What does chosen-prefix mean?

Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster," The attack will calculate suffixes for these two documents such that both documents have the same hash result. This means the attacker can then show some peop…

Honest question: has this any relevance outside of academia?

Re: OpenSSH 8.2

#17

Post by RL_Quine »

tialaramex wrote: post #15
mkj wrote: post #11

Earlier quoted context omitted.

The keys themselves are not bound to sha1 or sha256. The hash is just used for the ephemeral signatures during authentication (or certificates as mentioned in the release notes). "ssh-rsa" signature scheme at runtime (sha1) will be deprecated, but rsa keys themselves are fine (edit typo name)

Indeed, and so to actually use this $50k attack on SSH you'd need to somehow arrange for your target to pick random numbers you expected so that your attack works. But for clarity, OpenSSH isn't saying this can be used against SSH today - the deprecation is because we should abandon broken hashes before they actually cause us harm, not wait until after. Don't Walk Past.

People are still obviously using 1024 bit RSA keys which are more of a problem.

Re: OpenSSH 8.2

#18

Post by noodlesUK »

zimmerfrei wrote: post #9
RL_Quine wrote: post #4

Earlier quoted context omitted.

Just for fun, most users on Github have RSA keys exclusively. Did you know that your SSH keys are public on Github? https://github.com/taylorotwell.keys https://github.com/alexcrichton.keys https://github.com/andrew.keys https://github.com/egoist.keys https://github.com/fabpot.keys Some of the most popular users even have DSS keys.

You are conflating RSA (the algorithm) with "ssh-rsa" (the option of the SSH suite indicating authentication with RSA in combination with SHA-1). They deprecate the latter. Other options also based on RSA such as "rsa-sha2-256/512" are fine and will remain supported. In other words, the security problem is not with RSA per se. Having said that, I have not checked whether the people you list have RSA keys bound to SHA…

With this in mind, can gpg-agent be configured to use a better hash function with its RSA keys for use in SSH?

Re: OpenSSH 8.2

#19

Post by tulir »

microtonal wrote: post #7

The FIDO/U2F support is really nice! Though I had a question about this: is it only necessary for the client to use an OpenSSH version (>= 8.2) that supports this, or should the server also have support?

I'm pretty sure the server also needs to support it. The U2F signature stuff is different from SSH, so it needs a new authentication protocol: https://github.com/openssh/openssh-portable/blob/master/PROT...

Re: OpenSSH 8.2

#20

Post by tialaramex »

_pmf_ wrote: post #16
tialaramex wrote: post #13

Earlier quoted context omitted.

Chosen prefix means somebody doing this attack gets to pick the start of both the colliding documents. For example maybe I want two children's stories, one which starts "Donald was an innocent young boy," and the other begins "Steve was a corrupt old gangster," The attack will calculate suffixes for these two documents such that both documents have the same hash result. This means the attacker can then show some peop…

Honest question: has this any relevance outside of academia?

Sure.

Consider the Web PKI ("SSL Certificates"). Suppose you have a web site pmf.example it is of course pretty easy to get yourself a certificate to make https://pmf.example/ work, today for free but even many years ago it was pretty affordable from several commercial vendors.

The way those certificates work is they use a digital signature based on a hash algorithm, the CA uses its private key to sign the hash, and that's how computers can immediately tell a real certificate from a bogus one and be sure this is really news.ycombinator.com and not say, your ISP's advertising front end injecting a "special offer". The CA will refuse to give you a certificate for google.com or news.ycombinator.com because those aren't yours.

But using a chosen prefix attack you can create two documents with the same hash. One of them might be a fairly ordinary looking certificate for pmf.example that you're entitled to, the other says you're google.com

You get a CA to sign the first certificate, then you simply snip off their signature and attach it to the second one, since their hashes are the same the signature matches. You now have a valid certificate for google.com. Not theory, practice, this was really done with an earlier broken hash, MD5.

e.g. https://hackaday.com/2008/12/30/25c3-hackers-completely-brea...

A similar trick, probably done by or on behalf of the US and/or Israeli governments makes Flame work by colliding MD5 for code signing. That uses a collision nobody publicly knew about, which is a weird and expensive thing to do but of course governments have lots of money.

https://en.wikipedia.org/wiki/Flame_(malware)

Post reply on HN