First 32 secret key bytes are always same

Question

First 32 secret key bytes are always same

smrt28 opened this issue 6 years ago · 6 comments

Does it make sense to store the first 32 bytes of the secret key since they seem to be always the same?

$ cat ~/.config/enchive/enchive.sec | xxd
00000000: 0000 0000 0000 0000 0003 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000020: a8e6 ea13 c621 1381 1be1 f0b9 a88f 3989  .....!........9.
00000030: 2dd3 0613 0535 16fb dffa ce61 cf2d 9977  -....5.....a.-.w

Answer 1 · 2019-01-22T08:26:59.000Z

mine is different, so I think you just leaked part of your secret key

Answer 2 · 2019-01-22T08:37:39.000Z

mine is different, so I think you just leaked part of your secret key

This is because you set a passphrase. If you set none, you'll get the same behavior. Seems the first 32 bytes of your secret key are just encrypted zeros with 1bit set somewhere in 9th byte. And this is definitely not my secret key in use. ;-)

Answer 3 · 2019-01-22T08:39:24.000Z

This is because you set a passphrase. If you set none, you'll get the same behavior.

Oh, yeah right

And this is definitely not my secret key in use. ;-)

:D

Answer 4 · 2019-01-22T13:24:53.000Z

The secret key file format is "documented" by the beginning of the functions write_seckey() and load_seckey() where it's laid out plainly and simply. Here's a summary: IIIIIIIIViPPHHHH HHHHHHHHHHHHHHHH KKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK I = IV, used when encrypting the private key V = file version (ENCHIVE_FORMAT_VERSION), in case it ever changes i = power-of-two protection key derivation iterations P = unused padding (zeros) H = protection key hash, checks that you entered the right passphrase K = the secret key, optionally encrypted If you don't use a protection key (-u, or you accepted "empty for none"), then I, i, and H are all zero since they're unused, and K is your unencrypted secret key. That's why you're seeing all these zeros. This also means you just publicly posted an unprotected secret key, so make sure don't use that key.

Answer 5 · 2019-12-29T23:35:36.000Z

FWIW - in the above diagram provided by sketo, I believe the "file version" and "power-of-two protection" places are reversed...should be as follow:

IIIIIIIIiVPPHHHH

Answer 6 · 2019-12-30T00:56:52.000Z

Oops, yes, that's correct, @cyb3rz3us.