On 6/10/2015 at 4:54 PM, "Daniel Kahn Gillmor"
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
We'd also want to provide guidance that encourages signalling to
the user somehow that while the decryption was successful, the
confidentiality of the content can't be assured. Some similar
semantics should be exposed about the verified signature being unreliable
due to known-weak crypto.
=====
There are also some other issues which might be useful to bring to the user's
attention.
Here is one, but am not sure if the 4880 revision is the place for it, or if it
belongs more in some tutorial.
When GnuPG/PGP symmetrically encrypts a message, there is no padding added to
the plaintext before encryption.
As a result it is possible to tell from PGPDump if the plaintext of two
different symmetrically encrypted messages differ by only one character.
Here are some examples of PGP symmetrically encrypted messages consisting of
only the word 'no' or only the word 'yes' :
Checking the messages in PGPdump, http://www.pgpdump.net/, and
looking at the 'Symmetrically Encrypted Data Packet' analysis,
instantly distinguishes between plaintexts of different lengths.
Here are 3 sets of PGP symmetrically encrypted ciphertexts, each set
consisting of 'no' and 'yes', followed by the PGPdump analysis.
*****
plaintext: no
-----BEGIN PGP MESSAGE-----
Comment: TWOFISH passphrase: qwertyuiop
jA0ECgMIH73FxczREUpg0kUBBSTGKlLao/fpnIQ7L3+Ra2nAACC8sysTrBfpJMU0
RVU09heeNuPJYjdbT2hP+rJnCYj7cP0nTBXkybCienrodNmKScY=
=ocmH
-----END PGP MESSAGE-----
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - Twofish with 256-bit key(sym 10)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - 1f bd c5 c5 cc d1 11 4a
Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(69 bytes) <--
Ver 1
Encrypted data [sym alg is specified in sym-key encrypted
session key]
(plain text + MDC SHA1(20 bytes))
*****
plaintext: yes
-----BEGIN PGP MESSAGE-----
Comment: TWOFISH passphrase: qwertyuiop
jA0ECgMIH/9I4BkX+fdg0kYB26EwlSMKRRcm0ZnrDSII3vfRZPy1tOfU3qWneZWi
22B2epEtMB5NuiTz1s7NbDCGCo8dG8N8MzoLC6WISwHYYqTPgw1l
=Huvc
-----END PGP MESSAGE-----
PGPdump Results
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - Twofish with 256-bit key(sym 10)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - 1f ff 48 e0 19 17 f9 f7
Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes) <--
Ver 1
Encrypted data [sym alg is specified in sym-key encrypted
session key]
(plain text + MDC SHA1(20 bytes))
******
plaintext: no
-----BEGIN PGP MESSAGE-----
Comment: AES 256 passphrase: asdfghjkl
jA0ECQMIG13H6QXv9i5g0kUBn9G3703UbqhFEmqs0yctvbNbLR+aIJsEkMBkDezT
TM0+KR4QcueSWMnwUk+dVh3D7B2GMlwK2YtoE7Z0cO4P0ktgPp0=
=NXzG
-----END PGP MESSAGE-----
PGPdump Results
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - AES with 256-bit key(sym 9)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - 1b 5d c7 e9 05 ef f6 2e
Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(69 bytes)<--
Ver 1
Encrypted data [sym alg is specified in sym-key encrypted
session key]
(plain text + MDC SHA1(20 bytes))
*****
plaintext: yes
-----BEGIN PGP MESSAGE-----
Comment: AES 256 passphrase: asdfghjkl
jA0ECQMIvxt/F3fReGZg0kYBAVA8xJ9PMVw1eGpXwk1WQDR997Cljq96Gzux6ooH
R8LzXebgX/HtUgsQLSKIFzEpwLvmv7hmDxGaZXk4Q/JR5j3a9nZ2
=dZSw
-----END PGP MESSAGE-----
PGPdump Results
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - AES with 256-bit key(sym 9)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - bf 1b 7f 17 77 d1 78 66
Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes)<--
Ver 1
Encrypted data [sym alg is specified in sym-key encrypted
session key]
(plain text + MDC SHA1(20 bytes))
*****
plaintext: no
-----BEGIN PGP MESSAGE-----
Comment: 3DES passphrase: zxcvbnm
jA0EAgMITph9qaozSw5gySYXdnPe+HrZDbe1UdeYqgjWGnCmcyfGvzGnNu2Wn9qO
f615g/OI9A==
=ssLD
-----END PGP MESSAGE-----
PGPdump Results
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - Triple-DES(sym 2)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - 4e 98 7d a9 aa 33 4b 0e
Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(38 bytes)<--
Encrypted data [sym alg is specified in sym-key encrypted
session key]
*****
plaintext: yes
-----BEGIN PGP MESSAGE-----
Comment: 3DES passphrase: zxcvbnm
jA0EAgMI75uPvU83l/1gySdLWM29FolWYbqieErp4Y0U1M/LSGiIMO9zHrLMWK6U
rb8wDPi3UcU=
=UQyJ
-----END PGP MESSAGE-----
PGPdump Results
Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
New version(4)
Sym alg - Triple-DES(sym 2)
Iterated and salted string-to-key(s2k 3):
Hash alg - SHA256(hash 8)
Salt - ef 9b 8f bd 4f 37 97 fd
Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(39 bytes)<--
Encrypted data [sym alg is specified in sym-key encrypted
session key]
*****
As an additional oddity in the PGP armoring, for PGP symmetrically
encrypted texts, it is possible to distinguish between 'no' and 'yes'
just by briefly *looking* at the ciphertext.
The 'no' ciphertext has a padding character added, '=' to the end of
the ciphertext, on the line before the checksum, while the 'yes'
texts do not.
(In the 3DES example, there is an 'extra' '=' for the 'no'.
Have tested this for several 'either/or' messages of different
lengths :
(accept, decline), (pardon, execute), (pass, recommend), etc.
and it is always possible to distinguish between them in PGPdump, even
when the messages is signed and encrypted to a public key.
For a third party checking PGP messages, it is easy to encrypt these
plaintext sets to any public key, and check the length of the
Symmetrically Encrypted Packet in PGPdump, and reasonably infer which
of the either/or set is sent.
There is a simple workaround to prevent this type of analysis:
Just press the spacebar to add empty characters to a decided length (e.g. no
followed by 6 spaces or 'yes' followed by 5 spaces).
Again,
Sorry if it does not belong in the 4880 revision,
but wanted to bring it up to hear where the best place is to alert users to it,
who might otherwise thing that conventional encryption of short messages does
not offer a way to make a good guess at the content.
vedaal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp