Re: Oracle behavior in Gnupg? // (was 'possible bug in gpg?')

2012-07-31 Thread Ben McGinnes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 31/07/12 1:14 AM, David Shaw wrote:
 
 Yes, this is expected behavior.  It follows from what I explained 
 earlier in this thread.  When you use --override-session-key, you 
 bypass the quick check (after all, you gave the override key -
 what is there to check?) so you are seeing GnuPG choke on the
 invalid OpenPGP structures resulting from the garbage decryption.

On a related note, is it possible to extract the session key
(--show-session-key), but without decrypting the file in the process?
Just obtain the session key and stop there?  I've already tried -n
(--dry-run) and that still decrypts the file.


Regards,
Ben

-BEGIN PGP SIGNATURE-

iQGcBAEBCgAGBQJQF6uvAAoJEH/y03E1x1U8yrkL/1M6WOjwhLQ28iD5Bg+Ensu0
oezAbRumzdCe9l2H0seZ7NG79+/mLwlzIuVXe2IN10my2daesLfzHGyWNsj9bM/x
BNOpM+daBLd+lb9ceTsDayTbcYkpHbkhNW99UR50N5fNJWEeNwk6ukjk0c3QIXhk
HyoQG+OCzNc4W48mCWwt5tz3IObdjvzlpn/rll9n7i55BQIlwCd5TqfoWU8eSkFW
xzvT50P9rhZ0SaY7FVH1J6TYUKh7dN4IDv2jOUPghtGKkBh36bwQmfOSjmuwxm2w
SGx7eCKGoRx1M3JrkZKzwepl5VZtDhiERI9e3v1uz0tYsdBaBNzobkfu+am1PiD4
oMh1ic7OazieqCcfNYJyi5pBAIXq1oc71YyVzlNVlndmHAgu13o6eymijwb8EQqg
x1YcDG9RYCay4gJ5tzURahwpBRAz85znQDjjD20GA/Ocdgez5qDgLCeVScy/1+RG
xnPiNzPyEOjR73yDtIWPfgoHKtsuH+WjHuCVIs1BSQ==
=CxOe
-END PGP SIGNATURE-

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Oracle behavior in Gnupg? // (was 'possible bug in gpg?')

2012-07-30 Thread vedaal
While playing around with --override-session key , have noticed 
that gpg gives many different sets of error messages when trying 
out different session keys.

Here is an interesting example:

First, the gnupg encrypted text:

-BEGIN PGP MESSAGE-
Version: GnuPG v1.4.12 (MingW32)
Comment: encrypted to my default public key

hQIMA1BvT6HTX7GGAQ/+KUw1RNONlmWW/RvNzAlZmS4cOUm7ioVnJc8kgtSgnBbS
k952Lb6x5VaUyUbvXoNTeEdQGF1wJrDnV8Oz6VwqG/ZrlnUGOEFlGS9Mr2RZiktV
eqG7jUFWnD9yyedbWqFJv9MND7QlAuZ1uikKPfATjrGWq+fkqb1bFAT0745BEaOL
7VQ988rUsjf7TrS0+NIIA5qjLZeS49vaUY/ZDqeVsaliweTkegBzhWftpMz4dDpE
CxcAEZmEs4sleJq9BE0K/3A1U/1KDtzaYYRcsNFsIR6o3HhQyQ52zpmHwKY7WWc2
4ezMldyrcUGG7XSNGn2bkyIOfJmg7/1SJbpAjv6BjkH5G1IBY8R/ai4Lis58yeSr
6CbXDhQgowMRB1IH562SCSJyQIyu/GV+U5FBOOLkhWmqQjaNXP2LBgioMiyuBzsg
gyY+rDHX4R4iql7oLflPPQVGZWjtAYw4Q96Iv2HzCZH7Q3H4LRONAk1woQjyT3as
xKyxHNtqBhHfenTNep0ymeExYtcIsKYxLPj4WLRQ90rrOr1zY+N2eaWfDtIcEiAI
Fgf20sHePnFm+EqwQQF3MrdhHFWdQzX+BuXDHJ+maRWWeXNNMjSAF3LjP2i027zT
GglSUQOtRG7WGepM5sp2nNe+rfsCyHC3lIlujPHZ/LsdOi2IWeKKjOwUnfrp1LHS
SAE9acMxZ2laREHDcIX2N5GdtdYp3EoS/1mMIeKEN+i2PuSaX8Xq6ToexVfpRvcs
Mi6vGoldgMiOHN06g81oJdI4QYuQfudbEw==
=x/RS
-END PGP MESSAGE-

here is the REAL session key: 
10:A57B66F81B20273C587619AEA4C839D376DF50D23C946E97FB290D01CE
9E1F8D

-

Here is a 'starting' trial session key
(chosen as a start as it's easy to describe and keep track of the 
changes)
10:123456789a123456789b123456789c123456789d123456789e123456789f1234

Here is the gpg output:

gpg --override-session-key 10:123456789a123456789b123456
789c123456789d123456789e123456789f1234 e:\jt1.txt.asc
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.4.12 (MingW32)
gpg: armor header: Comment: encrypted to my default public key
:pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186
data: [4094 bits]
gpg: public key is D35FB186
gpg: public key encrypted data: good DEK
:encrypted data packet:
length: 72
mdc_method: 2
gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01-
22
  vedaal nistar (previous addresses were spam flooded) 
ved...@nym.hush.com

gpg: TWOFISH encrypted data
gpg: [don't know]: invalid packet (ctb=37)
gpg: mdc_packet with invalid encoding
gpg: decryption failed: invalid packet
gpg: onepass_sig with unknown version 146
-

Here is the session key with the REAL first 4 characters of the 
session key:

10:A57B56789a123456789b123456789c123456789d123456789e123456789f1234

Here is the gpg output:

gpg --override-session-key 10:A57B56789a123456789b123456
789c123456789d123456789e123456789f1234 e:\jt1.txt.asc
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.4.12 (MingW32)
gpg: armor header: Comment: encrypted to my default public key
:pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186
data: [4094 bits]
gpg: public key is D35FB186
gpg: public key encrypted data: good DEK
:encrypted data packet:
length: 72
mdc_method: 2
gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01-
22
  vedaal nistar (previous addresses were spam flooded) 
ved...@nym.hush.com

gpg: TWOFISH encrypted data
:unknown packet: type 50, length 152
dump: 36 53 de 6e 59 4d d2 0f  f4 09 98 87 31 bc a9 3c  1e fd 11 8a 
ae 92 5e 14
  24: b8 d4 64 f5 be EOF
gpg: mdc_packet with invalid encoding
gpg: decryption failed: invalid packet
-

Have not tried all the 2^16 possiblities for the first 4 
characters, but the few that I have tried lead to the same error 
message as the first trial.

Could this be Oracle behavior on Gnupg's part, leading to a leak of 
the first 4 characters of the session key?

fwiw,

This doesn't extend to finding out the next 4 real characters of 
the session key.

Here is the gpg output when the first 8 real characters are used:

gpg --override-session-key 10:A57B66F89a123456789b123456
789c123456789d123456789e123456789f1234 e:\jt1.txt.asc
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.4.12 (MingW32)
gpg: armor header: Comment: encrypted to my default public key
:pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186
data: [4094 bits]
gpg: public key is D35FB186
gpg: public key encrypted data: good DEK
:encrypted data packet:
length: 72
mdc_method: 2
gpg: encrypted with 4096-bit RSA key, ID D35FB186, created 2008-01-
22
  vedaal nistar (previous addresses were spam flooded) 
ved...@nym.hush.com

gpg: TWOFISH encrypted data
gpg: mdc_packet with invalid encoding
gpg: decryption failed: invalid packet


Here is the gpg output when only the 2nd real 4 characters are 
used:

gpg --override-session-key 10:123466F89a123456789b123456
789c123456789d123456789e123456789f1234 e:\jt1.txt.asc
gpg: armor: BEGIN PGP MESSAGE
gpg: armor header: Version: GnuPG v1.4.12 (MingW32)
gpg: armor header: Comment: encrypted to my default public key
:pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186
data: [4094 bits]
gpg: public key is D35FB186
gpg: 

Re: Oracle behavior in Gnupg? // (was 'possible bug in gpg?')

2012-07-30 Thread David Shaw
On Jul 30, 2012, at 10:45 AM, ved...@nym.hush.com wrote:

 While playing around with --override-session key , have noticed 
 that gpg gives many different sets of error messages when trying 
 out different session keys.

[examples]

 Borh examples give error messages identical to the first one, 
 except that when the first 8 real characters are used, the error 
 message of 'gpg: [don't know]: invalid packet (ctb=37)' is not 
 present,
 and when the second real 4 characters are used, there is a 
 'different' error message of 'gpg: [don't know]: invalid packet 
 (ctb=32)'.

Yes, this is expected behavior.  It follows from what I explained earlier in 
this thread.  When you use --override-session-key, you bypass the quick check 
(after all, you gave the override key - what is there to check?) so you are 
seeing GnuPG choke on the invalid OpenPGP structures resulting from the garbage 
decryption.

 Anything real about the 'oracle' action in any of this ?

It's only an oracle if you return this output to the attacker, or in some other 
way allow the attacker to see differences (timing, for example) in the 
responses to what he submits to you.

Don't do that ;)

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users


Re: Oracle behavior in Gnupg? // (was 'possible bug in gpg?')

2012-07-30 Thread Thomas Harning Jr.
On Mon, Jul 30, 2012 at 10:45 AM,  ved...@nym.hush.com wrote:
 While playing around with --override-session key , have noticed
 that gpg gives many different sets of error messages when trying
 out different session keys.

... CUT ...

 Borh examples give error messages identical to the first one,
 except that when the first 8 real characters are used, the error
 message of 'gpg: [don't know]: invalid packet (ctb=37)' is not
 present,
 and when the second real 4 characters are used, there is a
 'different' error message of 'gpg: [don't know]: invalid packet
 (ctb=32)'.

 Anything real about the 'oracle' action in any of this ?


 vedaal

Should we be worried about oracle behavior on a local running
application? It seems oracle behavior is all the rage even though it
makes ZERO sense on a local machine unless there is obfuscation
involved. On a local machine, you could take the data and just run the
algorithms yourself.

Does anyone run gpg on a server and let people send arbitrary data to
it? If so, then I'd suggest that a quiet execution be performed that
way only the exit code can be used that it's failure.

-- 
Thomas Harning Jr. (http://about.me/harningt)
Please support my wife as she runs her first marathon to raise $2,620 for
St Jude Children's Hospital - http://heroes.stjude.org/jenniferharning

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users