enchive
enchive copied to clipboard
First 32 secret key bytes are always same
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
mine is different, so I think you just leaked part of your secret key
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. ;-)
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
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.
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
Oops, yes, that's correct, @cyb3rz3us.