

Detecting an asymmetric Curve25519 backdoor in RSA key generation algorithms - mukyu
http://samvartaka.github.io/backdoors/2015/09/03/rsa-curve25519-backdoor/

======
StavrosK
It seems trivial to avoid detection: Just generate a random number, and if
it's a valid x-coordinate, only then backdoor it. Sure, you'll only backdoor
half the keys, but then you have to weigh whether the probability of being
detected and severity of it is worth the cost.

------
ryan-c
If anyone's particularly bored, the password, from which the master key used
in my original backdoor is derived, should be fairly easy to crack. It is
eight nonrandom characters.

~~~
aexaey
Actually, you don't need the master password to recover. Reusing master hash
(MASTER_PUB_HEX) works just fine.

[https://gist.github.com/aexaey/3646bb438f8712cbadf5/revision...](https://gist.github.com/aexaey/3646bb438f8712cbadf5/revisions)

Scroll to the third change from the top - stupid github doesn't allow (an
obvious) way to make a direct link to a particular gist's revision.

~~~
ryan-c
That only works in your changed version because it incorrectly uses
MASTER_PUB_HEX as a private key.

~~~
aexaey
Well, that's the version that samvartaka linked to. ;-)

~~~
ryan-c
Well it isn't my code, which does not have that bug. Apparently it is possible
to update other peoples gists? WTF? I've emailed the author to fix the link.
I've also fixed the gist. No idea how that got there.

Mine is here:
[https://gist.github.com/ryancdotorg/18235723e926be0afbdd](https://gist.github.com/ryancdotorg/18235723e926be0afbdd)

Edit: Looks like you forked my code, replaced the curve25519 lib and broke the
NOBUS and forward secrecy properties, then Nightling forked your fork (making
no changes), and I accidentally hit fork on his fork.

~~~
brianclements
what a cluster fork

------
qrmn
Of course, the Elligator and related mappings allow for (a subset of) valid
curve points to be mapped to indistinguishable bit strings, which is very
handy in some protocols. A backdoor merchant using Elligator 2, or Elligator
Squared, in this particular setup wouldn't be detectable.

~~~
makomk
I don't think you even need anything that fancy - pretty sure just encrypting
the leak again with a fixed AES key would do the job well enough. If someone
manages to get hold of the AES key they could use it distinguish backdoored
keys from random, but at that point you've been caught anyway.

~~~
adg001
There are a number of properties that a carefully designed asymmetric backdoor
is expected to have. NOBUS (Nobody But Us) and forward-secrecy are among them.
With a forward-secret backdoor, if a reverse­-engineer breaches the key-
generator, then the previously stolen information remains confidential.

If the key-generator embeds a secret key (for seed exfiltration), the backdoor
design will never be robust against reverse engineering. In fact, exposure of
the embedded key gives to the attacker the ability to retroactively factor
with ease the moduli of public-keys generated in the past, and recover the
private-keys.

The designs of Curve25519 and illusoryTLS embed only an elliptic-curve public-
key. Therefore, the exploitation requires access to the associated private-key
/i.e., NOBUS property).

For the longer story about the sorrow state of the Web PKI and the nitty
gritty details on this cryptographic backdoor, you may want to review the
illusoryTLS whitepaper [http://conference.hitb.org/hitbsecconf2015ams/wp-
content/upl...](http://conference.hitb.org/hitbsecconf2015ams/wp-
content/uploads/2014/12/WHITEPAPER-The-illusoryTLS-Asymmetric-Backdoor.pdf)

