[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

identical input, different output?



I use scrypt[1] as a component of http://masterpasswordapp.com, a stateless GPL password "manager" which does away with password vaults and generates site passwords from memorable tokens only.

My usage of scrypt[2] involves little more than:
crypto_scrypt( (const uint8_t *)masterPassword, strlen(masterPassword), (const uint8_t *)masterKeySalt, masterKeySaltLength, MP_N,     MP_r, MP_p, masterKey, MP_dkLen )

Where:
- masterPassword is a C-string read from a file (file was not touched during these tests)
- masterKeySalt is determined based on external factors (was logged as constant during these tests)
- MP_N, MP_r, MP_p, MP_dkLen are constants defined as 32768, 8, 2 and 64 respectively.

This function always produces identical output, with the sole exception of a single instance I've seen where it produced different output.

This was logged as such:

[EXPECTED:]
userName: Robert Lee Mitchell
mpwConfigPath: /Users/lhunath/.mpw
masterPassword: banana colored duckling
Robert Lee Mitchell's password for ⛄:
key scope: com.lyndir.masterpassword
masterKeySalt ID: D006ACE8060B83938FE812CC1C20D74F4EE9F6F33C3A1BC48E6CC3C43BCDD541
masterKey ID: 98EEF4D1DF46D849574A82A03C3177056B15DFFCA29BB3899DE4628453675302 (derived in 0.20s)

[UNEXPECTED:]
userName: Robert Lee Mitchell
mpwConfigPath: /Users/lhunath/.mpw
masterPassword: banana colored duckling
Robert Lee Mitchell's password for ⛄:
[ ╚☻╯⛄ ]: key scope: com.lyndir.masterpassword
masterKeySalt ID: D006ACE8060B83938FE812CC1C20D74F4EE9F6F33C3A1BC48E6CC3C43BCDD541
masterKey ID: 4312E1DEB1BEC1305AC2DE3F366F91F8B39D130027206370FE2E23931C6920F1 (derived in 0.19s)

Where the "ID" output is the result of performing your SHA256_Buf on the buffer pointer and then formatting it as hexadecimal output using:
const char *IDForBuf(const void *buf, size_t length) {
    uint8_t hash[32];
    SHA256_Buf(buf, length, hash);

    char *id = (char *)calloc(65, sizeof(char));
    for (int kH = 0; kH < 32; kH++)
        sprintf(&(id[kH * 2]), "%02X", hash[kH]);

    return id;
}

My question:
Is there a theory that might explain this, or could there be a bug in the scrypt implementation used.  FWIW, this machine does not have ECC RAM.

[1] scrypt implementation used: https://code.google.com/p/scrypt/

— Maarten Billemont (lhunath) —

Attachment: smime.p7s
Description: S/MIME cryptographic signature