Live data from Hacker News

Dual_EC_DRBG backdoor: a proof of concept

blog.0xbadc0de.be

21–28 of 28 posts

Re: Dual_EC_DRBG backdoor: a proof of concept

#21
post #17

"I did not break the official algorithm. I do not know the secret value used to compute the Q constant, and thus cannot break the default implementation. Only NSA (and people with access to the key) can exploit the PRNG weakness." I found this note interesting. How big is the secret value used to compute the Q constant? Is it a single static value or does it vary? Would it be possible to brute force this? I'm not a c…

> I'm not saying this is better.

Introducing weaknesses which adversaries can exploit versus ones which they cannot? It is much better.

Re: Dual_EC_DRBG backdoor: a proof of concept

#22
post #20
post #19

Earlier quoted context omitted.

Right. I think the big issue is that we are one NSA key leak away from breaking every product that uses this type of encryption. It introduces a single point of failure.

Can't you say the same thing about SSL keys? One leak away and every gmail account can be MITM'd.

SSL certificates can be revoked.

Re: Dual_EC_DRBG backdoor: a proof of concept

#23
post #17

"I did not break the official algorithm. I do not know the secret value used to compute the Q constant, and thus cannot break the default implementation. Only NSA (and people with access to the key) can exploit the PRNG weakness." I found this note interesting. How big is the secret value used to compute the Q constant? Is it a single static value or does it vary? Would it be possible to brute force this? I'm not a c…

> but this makes it sound like ONLY the NSA could exploit this.

Exactly right, and that's why NSA can still claim with a straight face that they were not trying to go around breaking crypto in a generic fashion. Like Clipper and Lotus Notes's initial crypto support, NSA was trying to make the crypto safe against everyone but NSA.

Now this is one area where I disagree totally with NSA's actions, but it is true that the way they went about weakening Dual EC DRGB is more nuanced than simply inserting a secret backdoor that anyone could exploit.

Re: Dual_EC_DRBG backdoor: a proof of concept

#24
Here's an example in Sage, if the verbosity of OpenSSL code annoys you as much as it does me:

    n = 115792089210356248762697446949407573529996955224135760342422259061068512044369
    p = 2^256 - 2^224 + 2^192  + 2^96 - 1
    a = -3
    b = 41058363725152142129326129780047268409114441015993725554835256314039467401291
    E = EllipticCurve(GF(p), [a,b])
    P = E(48439561293906451759052585252797914202762949526041747995844080717082404635286, 
          36134250956749795798585127919587881956611106672985015071877198253568414405109)
    """
    Q = E(91120319633256209954638481795610364441930342474826146651283703640232629993874, 
          80764272623998874743522585409326200078679332703816718187804498579075161456710)
    """
    e = 0x12345678
    ei = inverse_mod(e, n)
    Q = e*P

    def to_bin(x): return ("%060x" % x).decode('hex')

    def from_bin(x): return int(x.encode('hex'), 16)

    def dual_ec_drbg(s, len):
        out = ''
        for i in range(0, len, 30):
            x, y = (s*P).xy()
            s = Integer(x)
            x, y = (s*Q).xy()
            r = Integer(x) % 2**240
            out += to_bin(r)
        return out[0:len]

    def recover_s(s0, s1):
        for i in range(2**16):  # For all possible 256-bit x
            r = i*2**240 + s0   # 
            if E.is_x_coord(r): # is valid x?
                R = E.lift_x(r) # Lift it to a point
                x, y = (R*ei).xy() # Undo s*Q
                s = Integer(x)
                x, y = (s*Q).xy() # Check if it matches next observed block
                if (Integer(x) % 2**240) == s1: 
                    return s # done
        return None

    import os
    # Get 3 blocks: 2 are for the break, the other to confirm prediction
    s = dual_ec_drbg(from_bin(os.urandom(16)), 30*3)
    s0 = from_bin(s[ 0:30])
    s1 = from_bin(s[30:60])
    s2 = from_bin(s[60:90])
    # Recover internal state
    s = recover_s(s0, s1)
    # Now try predicting something
    t = dual_ec_drbg(s, 30)
    assert( from_bin(t) == s2 )
    print "Done"

Re: Dual_EC_DRBG backdoor: a proof of concept

#25
post #22
post #20

Earlier quoted context omitted.

Can't you say the same thing about SSL keys? One leak away and every gmail account can be MITM'd.

SSL certificates can be revoked.

and the Dual_EC_DRBG specs allow for the user to supply their own values for P and Q (much like the author did). NSA only provides the default.

Re: Dual_EC_DRBG backdoor: a proof of concept

#26
post #22

Earlier quoted context omitted.

SSL certificates can be revoked.

and the Dual_EC_DRBG specs allow for the user to supply their own values for P and Q (much like the author did). NSA only provides the default.

TLS provides forward secrecy though, so leaking the SSL keys doesn't mean anything for those exabytes of recorded transactions the NSA is presumably saving for a rainy day. If the secret keys for the default Dual_EC_DRBG configuration are leaked, aren't there more serious implications?

Re: Dual_EC_DRBG backdoor: a proof of concept

#27

Earlier quoted context omitted.

and the Dual_EC_DRBG specs allow for the user to supply their own values for P and Q (much like the author did). NSA only provides the default.

TLS provides forward secrecy though, so leaking the SSL keys doesn't mean anything for those exabytes of recorded transactions the NSA is presumably saving for a rainy day. If the secret keys for the default Dual_EC_DRBG configuration are leaked, aren't there more serious implications?

Yes, the comparison was faulty.

Re: Dual_EC_DRBG backdoor: a proof of concept

#28

Earlier quoted context omitted.

and the Dual_EC_DRBG specs allow for the user to supply their own values for P and Q (much like the author did). NSA only provides the default.

TLS provides forward secrecy though, so leaking the SSL keys doesn't mean anything for those exabytes of recorded transactions the NSA is presumably saving for a rainy day. If the secret keys for the default Dual_EC_DRBG configuration are leaked, aren't there more serious implications?

Dual_EC_DRBG is a pseudo random number generator, so if it's compromised you could use the internal state to recreate the sequence of pseudo random digits from that point forward. SSL/TLS is protocol which incorporates a suite of algorithms for authentication, key exchange and encryption. So on that level, like the sibling comment mentions, they aren't really comparable. The part of the SSL/TLS protocol that really depends on the certificate is the authentication, though - Diffie Helmann can be done in the clear without compromising its security, and once you've established the key any algorithm can be used to encrypt. When you revoke a certificate, you're essentially saying that you suspect someone else may be able impersonate you on the internet, so don't trust anyone authenticating with it. The algorithm is secure, but the certificate is not.

The point I was trying to make is that if you suspect someone has compromised your certificate, you can revoke it to reestablish secure communications. If you suspect your random number generator has been compromised, you can likewise just change the configuration (assuming it's not hardcoded into some piece of cryptographic equipment).

Post reply on HN