It's a trick to prevent forging all the blocks by a single big account.

Sometimes verification faces a situation similar to


In this case it's impossible to make sure that X == Y.

It happens ~ each 4th time.

Could this be a flaw? I am as usual very humble about my knowledge around this things.. but there are some questions here though.
I hope i will understand this better afterwards.

In this function

Line 1349: static byte[] sign(byte[] message, String secretPhrase)
We call a function for creating a signature calling curve.sign..


                byte[] v = new byte[32];
                Curve25519.sign(v, h, x, s);
               
                byte[] signature = new byte[64];
                System.arraycopy(v, 0, signature, 0, 32);
                System.arraycopy(h, 0, signature, 32, 32);
               
                return signature;

In this case, as seen in the function below, the first 32 bits of signature will always be 0.


                 *   v  [out] signature value
                 *   h  [in]  signature hash (of message, signature pub key, and context data)
                 *   x  [in]  signature private key
                 *   s  [in]  private key for signing
                 * returns true on success, false on failure (use different x or h)
                 */
                public static final boolean sign(byte[] v, byte[] h, byte[] x, byte[] s) {
                       * v = (x - h) s  mod q  */
                        byte[] tmp1=new byte[65];
                        byte[] tmp2=new byte[33];
                        int w;
                        int i;
                        for (i = 0; i < 32; i++)
                                v = 0;
                        i = mula_small(v, x, 0, h, 32, -1);
                        mula_small(v, v, 0, ORDER, 32, (15-v[31])/16);
                        mula32(tmp1, v, s, 32, 1);
                        divmod(tmp2, tmp1, 64, ORDER, 32);
                        for (w = 0, i = 0; i < 32; i++)
                                w |= v = tmp1;
                        return w != 0;
                }

So i quote directly from wikipedia, and i have also read the RFC regarding elliptic curve algorithm.. i see that if s is 0 then we are fucked?
And since we copy v into signatures first 32 bits, we could assume this as s = 0? This will in that case break the algorithm below not going back too step 3 if r is zero.


    Calculate e = \textrm{HASH}(m), where HASH is a cryptographic hash function, such as SHA-1.
    Let z be the L_n leftmost bits of e, where L_n is the bit length of the group order n.
    Select a random integer k from [1, n-1].
    Calculate the curve point (x_1, y_1) = k * G.
    Calculate r = x_1\,\bmod\,n. If r = 0, go back to step 3.
    Calculate s = k^{-1}(z + r d_A)\,\bmod\,n. If s = 0, go back to step 3.
    The signature is the pair (r, s).

When computing s, the string z resulting from (m) shall be converted to an integer. Note that z can be greater than n but not longer.[1]

As the standard notes, it is crucial to select different k for different signatures, otherwise the equation in step 6 can be solved for d_A, the private key: Given two signatures (r,s) and (r,s'). This implementation failure was used, for example, to extract the signing key used in the PlayStation 3 gaming-console.[2]

Regards
j0b, operator in #nxtalk at irc.freenode.net

Do it and we will see. If this is the flaw then u'll get the reward.

This is not the injected flaw. But it doesn't mean that there r no other flaws. If u dig deeper and find something flawed u'll get a reward.

The Crypto  class implementation doesn't check the return value of sign(...). It should because it will detect if the signature is 0.

Good. We'll get some bitcoins to set a reward for Nxt crypto algo audit. Yes, bitcoins, not nxts, coz if the algo is flawed nxts won't be worth a lot .

This was taken from https://code.google.com/p/curve25519-java/

If u see no difference than u could assume that there wasn't a flaw injected.