Quote from: Come-from-Beyond on February 09, 2014, 06:20:11 PM

There are 2 options:

1. Patch Curve25519 class
2. Patch Crypto class

Option 1, unlike option 2, may lead to problems u can't even imagine. I would patched Crypto...

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Quote from: Come-from-Beyond on February 09, 2014, 06:41:51 PM

Common sense doesn't work in cryptography. The problem is easily solvable by another way, so everyone who uses ur fix is just looking for troubles.

The statement that changes in Curve25519 can't lead to private key leakage still require a proof. If u can't provide the math, then u should prove that current implementation was incorrectly translated into Java from the original.

It's not about common sense, it's about knowing and understanding underlying problems.

Let s be your secret/priv key.
public key is nothing more than G*s in very specific finite field.

Finding priv key, while having public key == DLP on elliptic curve.

NOW, signing is actually:
v * temp, where temp is related ONLY to PUBLIC key. (v is dependent ONLY on the data)

What BloodyRookie's patch does is changing v into v' and changing the above to:
v' * temp

This leads to following OBVIOUS implication:

If OLD/original sign() doesn't leak private key bits =then=> PATCHED sign() doesn't leak them.

(whatever old one leaks is up to you, I know it doesn't, cause it's NOT related directly to private key)