Dual_EC_DRBG backdoor: a proof of concept

I'm confused how this is valid, since he seems to be using the OpenSSL code without the patch[1] that actually makes Dual EC work and his patch doesn't (to my C-ignorant eyes) include the fix either. Does it fix it in another way?

[1] http://marc.info/?l=openssl-announce&m=138747119822324&w=2&x...

[2] Discussion: https://news.ycombinator.com/item?id=6949652

Re: Dual_EC_DRBG backdoor: a proof of concept

#5

Post by timtadh » Wed, Jan 01, 2014, 3:39 PM UTC

KwanEsq wrote: post #4

I'm confused how this is valid, since he seems to be using the OpenSSL code without the patch[1] that actually makes Dual EC work and his patch doesn't (to my C-ignorant eyes) include the fix either. Does it fix it in another way? [1] http://marc.info/?l=openssl-announce&m=138747119822324&w=2&x... [2] Discussion: https://news.ycombinator.com/item?id=6949652

perhaps it is related to this point, since that bug causes the algorithm to get "stuck".

    Why wasn't this bug caught in the FIPS 140-2 validation testing?
    - ---------------------------------------------------------------

    Not only the original validation (#1747) but many subsequent validations
    and platforms have successfully passed the CAVP[5] algorithm tests ...
    several hundred times now. That's a lot of fail.

    In test mode the implementation works fine both with and without
    additional data. In free running mode the bug is triggered by additional
    data on the first call, which is done automatically by the "FIPS capable"
    OpenSSL.

    Frankly the FIPS 140-2 validation testing isn't very useful for catching
    "real world" problems.

Re: Dual_EC_DRBG backdoor: a proof of concept

#6

Post by StavrosK » Wed, Jan 01, 2014, 4:17 PM UTC

"An hashing algorithm"? That struck me as odd, is this valid in any accent other than Cockney?

EDIT: Oh, he's a fellow Greek. That explains that.

Re: Dual_EC_DRBG backdoor: a proof of concept

#7

Post by X-Istence » Wed, Jan 01, 2014, 4:56 PM UTC

StavrosK wrote: post #6

"A n hashing algorithm"? That struck me as odd, is this valid in any accent other than Cockney? EDIT: Oh, he's a fellow Greek. That explains that.

"an hashing algorithm" is also valid as a way to say "one hashing algorithm".

I find myself adding a "n" to "a" quite a bit since a lot of times it seems to flow better than using "a".

Re: Dual_EC_DRBG backdoor: a proof of concept

#8

Post by StavrosK » Wed, Jan 01, 2014, 5:10 PM UTC

X-Istence wrote: post #7

StavrosK wrote: post #6

"A n hashing algorithm"? That struck me as odd, is this valid in any accent other than Cockney? EDIT: Oh, he's a fellow Greek. That explains that.

"an hashing algorithm" is also valid as a way to say "one hashing algorithm". I find myself adding a "n" to "a" quite a bit since a lot of times it seems to flow better than using "a".

Only if you don't pronounce the "h", which is pretty nonstandard.

Re: Dual_EC_DRBG backdoor: a proof of concept

#9

Post by badman_ting » Wed, Jan 01, 2014, 5:23 PM UTC

StavrosK wrote: post #6

"A n hashing algorithm"? That struck me as odd, is this valid in any accent other than Cockney? EDIT: Oh, he's a fellow Greek. That explains that.

Thanks for posting!

Re: Dual_EC_DRBG backdoor: a proof of concept

#10

Post by asveikau » Wed, Jan 01, 2014, 5:32 PM UTC

StavrosK wrote: post #6

"A n hashing algorithm"? That struck me as odd, is this valid in any accent other than Cockney? EDIT: Oh, he's a fellow Greek. That explains that.

Reminds me of some native English speakers who say "an historic ..." Pretty common even in accents that won't drop the H. Seems like that word is an outlier though.