Closed BrandonIngalls closed 8 years ago
Thanks for the info, we'll look into it today. Seems like a bug in our PGP library (via Go Crypto).
Looking into this a little more, it's slightly challenging for us to debug it because of course we can't see your secret key. Though it's definitely a bug in our Go code. Maybe you could help with some diagnostics. Do you have the private key locally? Can you try this command?
gpg --export-secret-key aa2553663a2bffe52cedfc05bdae5ed3d37a580f | gpg --list-packets
That will show the structure of your private key without showing the contents. Many thanks!
$ gpg --export-secret-key aa2553663a2bffe52cedfc05bdae5ed3d37a580f | gpg --list-packets
:secret key packet:
version 4, algo 1, created 1314303666, expires 0
skey[0]: [8192 bits]
skey[1]: [17 bits]
iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: 53b2c45492dde6db
protect count: 65536 (96)
protect IV: c1 9b f1 4b ca 7c a4 08
encrypted stuff follows
keyid: BDAE5ED3D37A580F
:user ID packet: "Brandon Ingalls@gmail.com (Public Email) <BrandonIngalls@gmail.com>"
:signature packet: algo 1, keyid BDAE5ED3D37A580F
version 4, created 1319933893, md5len 0, sigclass 0x13
digest algo 2, begin of digest b1 f2
hashed subpkt 2 len 4 (sig created 2011-10-30)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
subpkt 16 len 8 (issuer key ID BDAE5ED3D37A580F)
data: [8191 bits]
:user ID packet: "Brandon Ingalls (Private Email) <Brandon@Ingalls.io>"
:signature packet: algo 1, keyid BDAE5ED3D37A580F
version 4, created 1390774833, md5len 0, sigclass 0x13
digest algo 2, begin of digest 0d fa
hashed subpkt 2 len 4 (sig created 2014-01-26)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
subpkt 16 len 8 (issuer key ID BDAE5ED3D37A580F)
data: [8189 bits]
:user ID packet: "Brandon Ingalls (School Email) <blingall@mtu.edu>"
:signature packet: algo 1, keyid BDAE5ED3D37A580F
version 4, created 1390774869, md5len 0, sigclass 0x13
digest algo 2, begin of digest 3d c4
hashed subpkt 2 len 4 (sig created 2014-01-26)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
subpkt 16 len 8 (issuer key ID BDAE5ED3D37A580F)
data: [8192 bits]
:secret sub key packet:
version 4, algo 1, created 1314303666, expires 0
skey[0]: [8192 bits]
skey[1]: [17 bits]
iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: 53b2c45492dde6db
protect count: 65536 (96)
protect IV: cb ef ea 95 87 6f 99 6f
encrypted stuff follows
keyid: F35549862AB57309
:signature packet: algo 1, keyid BDAE5ED3D37A580F
version 4, created 1314303666, md5len 0, sigclass 0x18
digest algo 8, begin of digest 58 b5
hashed subpkt 2 len 4 (sig created 2011-08-25)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID BDAE5ED3D37A580F)
data: [8191 bits]
:secret sub key packet:
version 4, algo 1, created 1411432440, expires 0
skey[0]: [2048 bits]
skey[1]: [17 bits]
iter+salt S2K, algo: 3, SHA1 protection, hash: 2, salt: f8e237db83627613
protect count: 65536 (96)
protect IV: 0d 73 69 af df 8a 64 d6
encrypted stuff follows
keyid: F0AB78A2F198A378
:signature packet: algo 1, keyid BDAE5ED3D37A580F
version 4, created 1411432440, md5len 0, sigclass 0x18
digest algo 2, begin of digest 96 9f
hashed subpkt 2 len 4 (sig created 2014-09-23)
hashed subpkt 27 len 1 (key flags: 2E)
subpkt 16 len 8 (issuer key ID BDAE5ED3D37A580F)
subpkt 32 len 284 (signature: v4, class 0x19, algo 1, digest algo 2)
data: [8189 bits]
I had forgotten that my primary key was 8192 bits, I plan on wiping that key and starting from scratch. Would you like me to hold off on nuking my keybase profile until I have a chance to test the next release?
still looking into it some, that might be the issue indeed. how did you generate the key? and how did you upload to the keybase.io server? thanks!
I generated the key a few years ago, I cloned the source for gpg and edited the bit restriction from 4096 to 8192, then recompiled. I can't imagine that is too common of a practice though.
I don't remember exactly what the steps were, but I do remember I used the older client which was installed with the keybase-installer command. I uploaded a pre-existing key and did not have the keybase client generate a new one.
I needed to be able to use keybase so I ended up wiping the keys from my account and uploading new ones.
I am able to use the keybase go client with no issues now.
Summary
I have been unable to use keybase on any of the fresh installs of Fedora 23 that I have done, whenever I attempt to login I always get the same error.
I have tried using a paper key and my username / keybase passphrase, both of the methods end in the same results...
Version Information
RPM Information
Keybase Information
Extra Info
After a little debugging I noticed that it seems like the background process is the source of my issue, when I run the keybase login command with the --standalone option I am able to see the process die. I have posted the output from that command to PasteBin.