Opened 9 years ago

Closed 6 years ago

#3207 closed enhancement (wontfix)

limit more keys to the exponent we specify

Reported by: arma Owned by: nickm
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In 987190c2bc1 we started to require that certain keys have a public exponent 65537.

In particular, it looks like we covered the onion (circuit handshake) key, the onion (handshake) key for intro circuits, and the intro point service key.

A fellow on irc named 'signing_key' points out that we left out K_SIGNING_KEY. He noted that if we had enforced the exponent on that key in the past, CVE-2011-0427 might not have been so bad.

He also points out that we left out the onion key in the microdescriptor. The authorities will refuse the normal descriptor, so it is implicitly filtered now, but if we want it to be filtered we should do it clearly.

Child Tickets

Change History (15)

comment:1 Changed 9 years ago by arma

Are we ever going to want keys with different exponents, in the distant future? Or is it always a bad idea for sure?

My crypto crystal ball is not good enough, but some external advice might be good here.

comment:2 Changed 9 years ago by arma

More generally, we need to figure out why we're drawing a line with some keys on one side of the line and other keys on the other side.

The only keys I know of that may have been generated non-standardly are hidden service identity keys (I think that one's called R_PERMANENT_KEY) -- people have historically used tools like Shallot to brute force patterns into their .onion address for amusement.

comment:3 in reply to:  1 ; Changed 9 years ago by asn

Replying to arma:

Are we ever going to want keys with different exponents, in the distant future? Or is it always a bad idea for sure?

My crypto crystal ball is not good enough, but some external advice might be good here.

Cryptographically, I don't see any problems with this. OAEP solved same small exponents attacks years ago, and 65537 is not a small exponent either.
Wikipedia also says:
"The NIST Special Publication on Computer Security (SP 800-78 Rev 1 of August 2007) does not allow public exponents e smaller than 65537, but does not state a reason for this restriction."

rransom said on IRC that he didn't also restrict the identity key exponent because it's public in the TLS handshake and might be fingerprintable, which is a valid thought, but generally *most* RSA exponents are 65537 nowadays.

rransom also said that he had a patch for onion keys in microdescriptors that didn't get merged. He said he pushed it to his public repo but I didn't manage to find it.

comment:4 in reply to:  3 Changed 9 years ago by rransom

Status: newneeds_review

Replying to asn:

Replying to arma:

Are we ever going to want keys with different exponents, in the distant future? Or is it always a bad idea for sure?

My crypto crystal ball is not good enough, but some external advice might be good here.

Cryptographically, I don't see any problems with this. OAEP solved same small exponents attacks years ago, and 65537 is not a small exponent either.
Wikipedia also says:
"The NIST Special Publication on Computer Security (SP 800-78 Rev 1 of August 2007) does not allow public exponents e smaller than 65537, but does not state a reason for this restriction."

rransom said on IRC that he didn't also restrict the identity key exponent because it's public in the TLS handshake and might be fingerprintable, which is a valid thought, but generally *most* RSA exponents are 65537 nowadays.

rransom also said that he had a patch for onion keys in microdescriptors that didn't get merged. He said he pushed it to his public repo but I didn't manage to find it.

I said that I would push that patch, not that I had pushed it. And then I distracted myself for a few hours.

See hs-client-input-validation-fixes-022 ( git://git.torproject.org/rransom/tor.git hs-client-input-validation-fixes-022 ).

comment:5 Changed 9 years ago by nickm

Cherry-picked the head of that into maint-0.2.2 and added a changes file.

Should we check identity keys as well? I can't think why not to.

comment:6 in reply to:  5 Changed 9 years ago by arma

Replying to nickm:

Should we check identity keys as well? I can't think why not to.

"rransom said on IRC that he didn't also restrict the identity key exponent because it's public in the TLS handshake and might be fingerprintable, which is a valid thought, but generally *most* RSA exponents are 65537 nowadays."

I don't have a strong opinion either way.

comment:7 Changed 9 years ago by nickm

I'm not sure that's right. The identity key isn't send in the clear in the v2 tls handshake and won't be send in the clear in the v3 tls handshake envisioned in proposal 176. Does the signing key itself appear in an x509 certificate somewhere?

comment:8 Changed 9 years ago by nickm

Right; the most obvious thing to do here is probably just to enforce the requirement everywhere except for hidden service identity keys. Most everybody uses 65537 as an exponent in TLS rsa keys, so it's not a fingerprinting risk.

comment:9 Changed 9 years ago by nickm

Owner: set to nickm
Status: needs_reviewaccepted

Throwing this out of needs_review, since I believe we've merged all the pending pieces. The remaining piece is to enforce the exponent on identity keys. That could be done as a small patch any time in December, if we want it for 0.2.3. I don't believe it's going to create a fingerprinting opportunity; see reasoning above.

comment:10 Changed 9 years ago by Sebastian

Since there is discussion of maybe doing this soon, I'm tentatively moving this into the 0.2.3.x-final milestone

comment:11 Changed 9 years ago by Sebastian

Milestone: Tor: unspecifiedTor: 0.2.3.x-final

comment:12 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:13 Changed 8 years ago by nickm

Keywords: tor-relay added

comment:14 Changed 8 years ago by nickm

Component: Tor RelayTor

comment:15 Changed 6 years ago by nickm

Resolution: wontfix
Status: acceptedclosed

The correct fix here is to migrate away from RSA.

Note: See TracTickets for help on using tickets.