1

In order to construct a short, yet cryptographically strong verification code, I'm thinking about using the output of several hashes computed over the same data (device uuids + raw certificate data).

Pseudocode:

char *data[] = [clientUUID + serverUUID + certificateData];
uint16_t dataLength = length(data);
char *verificationCode[15];

sha256Hash[] = sha256(data, sizeof(data)); 
sha1Hash[] = sha1(data+sha256Hash, sizeof(data)+sizeof(sha256Hash));
md5Hash[] = md5(data+sha1Hash+sha256Hash, sizeof(data)+sizeof(sha256Hash)+sizeof(sha1Hash));

// Store length at start so the size of data can't vary
verificationCode[0] = ((char *)dataLength)[0]
verificationCode[1] = ((char *)dataLength)[1]

// Now fill the rest of the verificationCode with a mix of bytes from the different hashes
verificationCode[2] = sha256Hash[0] ^ sha1Hash[0] ^ md5Hash[0]
..
verificationCode[15] = sha256Hash[13] ^ sha1Hash[13] ^ md5Hash[13]

I'd then present the verification code as base64-encoded string to the user on both devices (computer + mobile device) to verify upon pairing. My thinking here is that it should be computationally very expensive to find a set of data with the same length that generates the same hash results across all three hashes - and hence the same verificationCode result.

However, I also see that using only a portion of the hashes should definitely weaken the protection.

Is a verification code like the one computed above secure for a short time window (think: couple of minutes)? Or is there an established and proven alternative I can use for a short, human-readable verification code ?

Felix Schwarz
  • 11
  • 2

1 Answers1

1

There should not be any need to use several different hashes. One such as SHA3 will provide what you need. A Hash, Salt, and Stretch configuration as provided by for example bcrypt or scrypt will add extra protection if you want it.

As for shortening the code, yes this will decrease security but the same length of a NIST recommended password should suffice: 8 characters

Jackoson
  • 133
  • 4