Open diafygi opened 9 years ago
I also have run into this issue exactly as @diafygi has described.
hi
we can support this easily, I think. can you please send us a copy of a key like this?
(a test key, don't send your actual secret key =)
Here's what I get by doing this. It seems like the S2K is easy to support.
# off=0 ctb=95 tag=5 hlen=3 plen=277
:secret key packet:
version 4, algo 1, created 1384458137, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
gnu-dummy S2K, algo: 0, simple checksum, hash: 0
protect IV:
keyid: 8F652698C330A72A
# off=280 ctb=b4 tag=13 hlen=2 plen=69
:user ID packet: "RSARSA KEY (RSA/RSA key generated by gpg) <rsarsa@pgpkey.example.com>"
# off=351 ctb=89 tag=2 hlen=3 plen=312
:signature packet: algo 1, keyid 8F652698C330A72A
version 4, created 1384458137, md5len 0, sigclass 0x13
digest algo 2, begin of digest 8f 5a
hashed subpkt 2 len 4 (sig created 2013-11-14)
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 8F652698C330A72A)
data: [2046 bits]
# off=666 ctb=b4 tag=13 hlen=2 plen=53
:user ID packet: "Security Team Victim <security.team.victim@gmail.com>"
# off=721 ctb=89 tag=2 hlen=3 plen=312
:signature packet: algo 1, keyid 8F652698C330A72A
version 4, created 1431532326, md5len 0, sigclass 0x13
digest algo 2, begin of digest 56 1e
hashed subpkt 2 len 4 (sig created 2015-05-13)
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 8F652698C330A72A)
data: [2047 bits]
# off=1036 ctb=9d tag=7 hlen=3 plen=966
:secret sub key packet:
version 4, algo 1, created 1384458137, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: 095743CA95C7DB0B
protect count: 20971520 (228)
protect IV: 45 15 60 44 36 7f 2a c2 cb 1f 5c c6 57 e7 c4 7f
skey[2]: [v4 protected]
keyid: 2325271F95BF86A1
# off=2005 ctb=89 tag=2 hlen=3 plen=287
:signature packet: algo 1, keyid 8F652698C330A72A
version 4, created 1384458137, md5len 0, sigclass 0x18
digest algo 2, begin of digest 31 f7
hashed subpkt 2 len 4 (sig created 2013-11-14)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 8F652698C330A72A)
data: [2044 bits]
monkey patching the code, seems to make it work:
e2e.openpgp.EncryptedCipher.prototype.unlockAndVerifyKey_ = function(decryptedKeyData) {
if (this.s2k_ instanceof e2e.openpgp.DummyS2k && this.s2k_.mode == e2e.openpgp.DummyS2k.GPG_modes.NO_SECRET) {
this.locked_ = false;
this.keyBytes_ = [];
return;
}
followed by:
e2e.openpgp.packet.SecretKey.parse = function(body) {
...
case e2e.openpgp.EncryptedCipher.KeyDerivationType.S2K_SHA1:
algId = body.shift();
s2k = e2e.openpgp.S2k.parse(body);
if (s2k instanceof e2e.openpgp.DummyS2k) {
encrypted = false;
kd = 0;
}
so, I guess it's a small patch.. I'll try to get to it unless someone else beats me to it.
GPG allows you to export your subkeys with with a blank primary key using the
gpg --export-secret-subkeys {key-id}
option. This is great if you want to keep your primary key air-gapped and have both a signing and encryption subkeys.Unfortunately, end-to-end raises a "Cannot get key from special locations!" error when trying to import just the subkeys.
Use case:
Reproduction steps:
gpg --gen-key
gpg --export-secret-subkeys > secret_subkeys.gpg
secret_subkeys.gpg
into the end-to-end keyring.What should happen:
When importing secret keys, blank primary keys should be skipped and still allow importing secret subkeys. That way, you can still decrypt and read messages sent to you without having to trust end-to-end with your primary secret key.