-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
First 32 secret key bytes are always same #26
Comments
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. ;-) |
Oh, yeah right
: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.
|
Does it make sense to store the first 32 bytes of the secret key since they seem to be always the same?
The text was updated successfully, but these errors were encountered: