Unusual (unintended?) behavor upon decryption of a message
Upon decryption of the attached message, the program requests a new passphrase. Then after any arbitrary string is entered (or nothing), decryption of the message fails. It does not matter if any private keys are held in gnupg (including the key of the intended recipient). Here is the message in question. How is this possible? -BEGIN PGP MESSAGE- Comment: GPGTools - https://gpgtools.org hQEMA8sGafEL0jk+AQgAkw42Raga96t+3DtGR2Hy0xLsOiabSrPIrdNP6gymn6Lw 8VLnKHcedpByZyOUd7ifgS+QiV6MlDov9z//9U5KTiD2oyAfJ5dB6/ZSpGiUftm/ 82dxSFfxhOASEQ5Cik1BViLK+n9+cYBUdPY/F2zh58x9Cr/g7RTIhHpyDwdzPW5X suYlxofpIV2R43/VNI4T6Mln6Ja4N5poadJVrbIkajPdRjFKBJ7xF5f8VDc4zIus hoJvfPQpUoWqn4SKXNpmjPGSMftUhMyHUMrIePbm0H/57tsd7GmPDfRcQ3eZZYP/ vFkhVY/HJnBIE283I0Vygo/Tgd5iJr71uFZFSy2Ko4wuBAMDAogT9pWed09F0u+G goArYxi0LD1f6cVlyNvNDqG9HrtC3Cae6YA03j1Z09LpAYrPm3wOGKKZIilc4frh alWflwPEbsxqBXYBJjUGRDMqMgsidX8QveJOKZpbSdW6edSurmMfRPxKA6RjWz9p C3L0N9XC6gZV2kludw8qfR8+AR9Hv+eGjaSm6K9Tk8tJNMTdnafPIKDIo5rAN4qV YDM+wVv6hs3x9Ng1BZfGWXAY37sclLjvRri/uIr1snQkfah/uvrWa+Zl9CfraEjA CSDNYTYDu4M0tkvf+ky0GMjeA84JS6OA9X6YsIDu9llsSKAfrNFmJszVRkNP/uqO gstLj0CEgS3noljhrvIsKbzNxmBmhoftIP+txeh0vpOw58cpB5XhV8jh4h/wBN+9 YNLeIz6uKN39tlU5E9zJ08OlWw7GxA6fkOqwGpVpI25A43ZWfG2WBvcueQFckq38 PgkfNrB+vgOODbwq0PAaA5oq6YXn7raXxmC+7p7cOUHXZlvq19ZN8YSM0lZi8GWs z2oVEGlkLgS95Mz1cwqe7CvhcZeKdsgWT+Gw0Pa32YKtXqgfdySZLttT/+5W2OI+ Q5o4gpRQ/269wGgRTJYSyQoxWgwWTRwkDq+1GVTMwP/M5hQNCWRIP30I48Gal1tr igyTtlXS/EG8PEbCs8hU86WdWWHGI7P8HbAhrkRmuQzF/KZ3hx8+7fmK3ULWxgb1 VvuRjtC6cerFWRGX9bONcnHAU6tuwHAN45/TVERNFrsuyRnjSCFnRQ2d0PcOVPvs Ed6pEjOn4QWP1qhyKvyPTJd6R+MBtJqRlZzCSNcXqCjGU6Z126Nx1WqjkxVv9m7c sW4HwS9VNSbjebypUtwHjSn/QORqKSNul1BEPe9x2YIOHHsFpYtsUzbzXvDblJ4F fx+pqkC7TKYcGTHcwEjQIy4F3ny3KkVNeJdU6/xfz39k/LJhyuAQ43bo1SyJA0Rg FyPTYCBajofY7jNrLzgNBRlbInMHv1SKGoiO5RKP2iW28W1y82fKujFYmmE1k0g2 8eBvkac8A/3B9gVc7/JCrpMAy3+bqM1MEb1dRtv92Uf1+aPGFSgboNhSAePZzGQZ ulTfoOUU =I9Fr -END PGP MESSAGE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
Le 19/11/2013 08:28, fuzzykitt...@riseup.net a écrit : Upon decryption of the attached message, the program requests a new passphrase. Then after any arbitrary string is entered (or nothing), decryption of the message fails. It does not matter if any private keys are held in gnupg (including the key of the intended recipient). Here is the message in question. How is this possible? In my opinion, this is a symetric crypted message. You need the exact password (called passphrase as well) to decrypt it, but it's not a double key cipher. -- Laurent Jumet KeyID: 0xCFAF704C ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: [tor-talk] [liberationtech] BitMail.sf.net v 0.6 - Secure Encrypting Email Client
I don't think that's possible at the moment. There are no deterministically built operating systems yet. This is rather sad. I think FreeBSD has a project somewhere trying to move that way. Hopefully all of the unix-likes are at least aware of the concept, if not having an actual project for it. Also, none of the BSD's have any built-in integrity in their repositories, they just insist their infrastructure and committers are infallible among other escuses. (Excepting DragonFly which uses git, don't know if they sign it though. Monotone seems better at that sort of embedded pki thing.). ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
On 19/11/13 10:15, Laurent Jumet wrote: In my opinion, this is a symetric crypted message. You need the exact password (called passphrase as well) to decrypt it, but it's not a double key cipher. You're only partly correct. Letting 'gpg2 --list-packets --list-only' inspect the message, I see: :pubkey enc packet: version 3, algo 1, keyid CB0669F10BD2393E data: [2048 bits] :symkey enc packet: version 4, cipher 3, s2k 3, hash 2, seskey 256 bits salt 8813f6959e774f45, count 9437184 (210) gpg: CAST5 encrypted session key :encrypted data packet: length: unknown mdc_method: 2 gpg: encrypted with 1 passphrase gpg: encrypted with RSA key, ID 0BD2393E So it can be decrypted either with the mentioned RSA key, or by some passphrase. There are two ways to get at the data. If you don't have that RSA key, programs will likely query you for the passphrase. If you do have the secret key for that RSA key, I suppose it will ask that first, although I'm not sure. It will ask for the passphrase for the RSA key, but I'm unsure if it will be the first passphrase it asks for. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
Pete Stephenson: 1. If you set the keyprefs in your gpg.conf configuration file before you generate a new key it will generate new keys with these stronger defaults rather than having you need to edit them later. See http://www.debian-administration.org/users/dkg/weblog/48 for details and examples. I also thought about recommending a gpg.conf with specific settings. Maybe this one: https://github.com/ioerror/torbirdy/pull/11 https://github.com/ioerror/torbirdy/blob/master/gpg.conf Not sure... What makes the page less complex and confusing? Explain how to set such options using command line or creating a gpg.conf? When one uses a Live system for its air gapped OpenPGP key, one would have to constantly remember re-creating this that gpg.conf. (Gone after reboot.) I'd like to call your attention to the cert-digest-algo SHA256 line -- this means that your primary key will make stronger signatures on other keys (e.g. your subkeys and other people's public keys). This is probably a Good Thing. This is important. Can this be set without using gpg.conf? 2. Have you considered adding TWOFISH and BLOWFISH to the list of ciphers? I put TWOFISH after AES256 and before AES192, and I put BLOWFISH after AES but before CAST5. I like having diverse, strong ciphers available to those who might elect to use them. Since the versions of GnuPG I use support those ciphers and they're generally well-regarded I see no reason to exclude them, but your mileage may vary. No, I haven't considered it, don't feel I am competent for such a discussion. I am ignorant about the nuances which ciphers are better/worse/when/etc. and following recommendations from here: https://github.com/ioerror/torbirdy/blob/master/gpg.conf 3. When generating the key and you're prompted to pick a key type, I recommend selecting #4 (RSA (sign only)). This generates only the primary signing/certification key but does not generate an encryption subkey at the same time. Later you can add the encryption and signing subkeys. This can be useful if you want to mix-and-match algorithms and expiration dates. [...] Implemented this suggestion. 4. Are there any known issues with your air gapped system being the same physical hardware as your everyday system even if you use a LiveCD? I don't know if there'd be the potential for hardware compromises. Depending on one's security needs, it might be useful to get a separate, isolated, never-connected-to-the-internet computer specifically for high-security needs. (See https://www.schneier.com/blog/archives/2013/10/air_gaps.html for some pointers.) I added this: You can boot a Live DVD or an operating system installed on external media such as USB (recommendation: use full disk encryption). Using a separate physical hardware is better than just booting another operating system, but still, using another operating system is better than nothing. 5. Smartcards are also useful, as you can generate keys on your isolated computer, back them up safely, then copy the keys to the smartcard. You can then use the smartcard on your everyday system without risk of exposing the private keys. I added this suggestion as well. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
Hauke Laging: Am Mo 18.11.2013, 17:21:22 schrieb adrelanos: Hi, An article about air gapped OpenPGP keys has been written by me: https://www.whonix.org/wiki/Air_Gapped_OpenPGP_Key Please leave feedback or hit the edit button. By default GPG creates one signing subkey (your identity) and one encryption subkey That's wrong. The default is a mainkey for signing and a subkey for encryption. Fixed that. This new subkey is linked to the first signing key. ? Fixed that. Your master keypair is the one whose loss would be truly catastrophic. I would not put it that way. If it is just lost then the key will expire (if it has an expiration date as it should) as you cannot extend its validity time. So you need a new key. That is unpleasant but usually not as unpleasant as compromised decryption or signature keys. If you state something like that I think you should explain it. I agree with that. Originally intended to write compromise instead of loss. When I write compromise, that sentence should be correct. Using the highest possible value for key length helps protect you from that scenario. Don’t use GPG’s default of 2048! That argument doesn't make any sense for a key copied to your every day operating system. The whole context is: When you create your new keypair, use the highest possible values for key length. As computers get more powerful and storage gets cheaper, it’s conceivable that a nasty person could archive a message that’s unbreakable today, then in the future break it using a more powerful computer. Using the highest possible value for key length helps protect you from that scenario. Don’t use GPG’s default of 2048! Why doesn't tbhat make sense? If your master keypair gets lost or stolen, this certificate file is the only way you’ll be able to tell people to ignore the stolen key. This is important, don’t skip this step! I have never understood why people seem to believe that they cannot safely store a key backup (including the passphrase if necessary) but can safely store a revocation certificate. I don't understand. Clean up our temporary file. rm subkeys Why should one remove this file? Probably not that important. It's not required anymore. When later new subkeys are created, that file would have to be updated. Removing it to avoid confusion. And it it really a good idea to use the same passphrase for both mainkey and subkeys? From a security perspective, clearly no. From a usability perspective, yes. Above I am suggesting to store the key backup on a fully encrypted disk, so the passphrase for the mainkey doesn't matter if you assume, the full disk encryption of that disk is safe. The pound sign means the signing subkey is not in the keypair located in the keyring. No, it means that the mainkey has been replaced by a stub. I added this as a footnote. Securely wiping of data is a difficult issue. We believe it is safer to create a new keypair (a new secring.gpg) than trusting gpg to remove the private master key from secring.gpg. We are talking about a secring.gpg in RAM as the key is generated on a secure system running some live Linux CD/DVD? That would be advisable. Our every day operating system never gets to see our OpenPGP master key But it sees the mainkey's passphrase... True. It will take me some time to translate this in English but I have written a bash script which creates a new key with two subkeys and outputs a set of files (with different passphrases) and two directories and even allows you to easily certify other keys and create mainkey signatures immediately after key creation: 0x11DB2900.public.asc 0x11DB2900.public.asc.asc 0x11DB2900.secret-mainkey.asc 0x11DB2900.secret-mainkey-only.asc 0x11DB2900.secret-subkeys.asc _gnupg-mainkey/ _gnupg-subkeys/ http://www.openpgp-schulungen.de/scripte/keygeneration/ explained here: http://www.openpgp-schulungen.de/inhalte/einrichtung/materialien/keygen-anleitung-info.html Or download the whole script collection here and run ./start.sh: http://www.openpgp-schulungen.de/download/ This is most interesting. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
Robert J. Hansen: Please leave feedback or hit the edit button. Maybe it's useful for someone. It's under public domain. A major omission: What is this, why should I care, and what security risks does it mitigate? Without that, the article is useful only to people who have already been convinced of the importance of an airgapped certificate. If you can address those three questions the page will become much more useful to people who don't know what an airgapped certificate is or in which circumstances it might be useful. I agree with that, I've never been good at explaining the why, so this time I omitted it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
On Tuesday, November 19, 2013 at 3:51 AM, fuzzykitt...@riseup.net wrote: Upon decryption of the attached message, the program requests a new passphrase. Then after any arbitrary string is entered (or nothing), decryption of the message fails. It does not matter if any private keys are held in gnupg (including the key of the intended recipient). Here is the message in question. How is this possible? = As Peter answered, this is message encrypted both to a Public Key and also symmetrically to a passphrase only. If, after gnupg asks for the message, any string other than the correct passphrase is entered, then there will be an error message. (The interesting part is that the error message changes with the string used as a passphrase.) Here is my recreation of this type of encrypted message, both to my public key, and conventionally, to only a passphrase, using the following command: V:\gnupggpg -a -c -e -r D35FB186 e:\de1.txt -BEGIN PGP MESSAGE- Version: GnuPG v1.4.15 (MingW32) Comment: Acts of Kindness better the World, and protect the Soul hQIMA1BvT6HTX7GGAQ//Wi164/mZry2Iwe87izC/lNKfaKswBHMuon5oBDoAa1lm RkcA7Ohv4ahAW7DZh6ugsiNOZogmcNx02BTalAeGzt1INwvM1D3dXraC+wRHE/39 tgx7DsLDK8gbwtTja2iFhbWSsh/Bpxyt8+37wy6eS6NYiWRFsbi7unxbKkfNQtRg WQufOhYcSY2SytW6xPxC0Va/CTSYI8++RHOWeZRLVW89irv48U60vZQOHx1xQ3JB 3Hq5PsJeMAmBXr/W6b7ivYWlExrxMdiF8AeuGsxOzarViAzYUYP/cd7M1HI4gpYK DtQ4ZIT+x6BWQmibBIh5y2R0ZoGJLEHSsS6vMV5oXiB5w8wTMFUWj0HKFlb8nPgH fGR7B2E6RPVJ8VFOhOhLkeOf7vJc4FtAQCUvEznViqhgrsJa+is7pcBmF2/ny78f N9rYKHGQdDXyu4WOOz+gecdDq6H7SwFaqe0hGs0bDx/8FH4/9q4wHIr7K+rYvGOY hGwetUgNdPTafkTdXCUoaPlGxG3tObfUc4UtP+v+FyHDfkJ9pwHits5PO4Pzr+kE 71ogzObe127cr2Tw2VJiyieAWHhTR59T2pXWIfbzmA1+e+yMHUdaV1XgyzQwBGlG bbi5MsAcKdprN8SgeSTRB/1Vd9Rrr4iRkYoNuPTIUCEhf1o6xdOXpBJjL6JPX3uM LgQKAwhNVbIC8B7iZ2CA8sUfrvT1/XNrk63FLcMeB+SENdrto5kqyeMUUj3xLKTS RwHyCW71fhEfZoi6Qe/t0+OelLVRjsv5OmIrstTovMCFDpm7T8dFLbMgv2sMi48Y 7gEyEa0b3m1oOzXQIVAlU3Cn0TRicSMy =AwHd -END PGP MESSAGE- (the passphrase is: sss) Here is what gnupg does when I enter the wrong passphrase for my key, but the correct one for the symmetrically encrypted part: V:\gnupggpg --list-packets e:\det1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.15 (MingW32) gpg: armor header: Comment: Acts of Kindness better the World, and protect the S oul :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4095 bits] gpg: public key is D35FB186 You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded) ved...@nym.hush.com 4096-bit RSA key, ID D35FB186, created 2008-01-22 gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded) ved...@nym.hush.com 4096-bit RSA key, ID D35FB186, created 2008-01-22 gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded) ved...@nym.hush.com 4096-bit RSA key, ID D35FB186, created 2008-01-22 :symkey enc packet: version 4, cipher 10, s2k 3, hash 8, seskey 256 bits salt 4d55b202f01ee267, count 65536 (96) gpg: TWOFISH encrypted session key :encrypted data packet: length: 71 mdc_method: 2 gpg: encrypted with 1 passphrase 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: public key decryption failed: bad passphrase :symkey enc packet: version 4, cipher 10, s2k 3, hash 8, seskey 256 bits salt 4d55b202f01ee267, count 65536 (96) gpg: TWOFISH encrypted session key Enter passphrase: gpg: TWOFISH encrypted data :compressed packet: algo=1 :literal data packet: mode b (62), created 1384876034, name=de1.txt, raw data: 11 bytes gpg: decryption okay gpg: session key: `10:549F3BBBA12DD79C0019854AED854964931A9C2349870785130B0E863F C4C3F0' Now, here is what gnupg does when the 'incorrect' passphrase is given for the symmetric part: V:\gnupggpg e:\de1.txt.asc gpg: armor: BEGIN PGP MESSAGE gpg: armor header: Version: GnuPG v1.4.15 (MingW32) gpg: armor header: Comment: Acts of Kindness better the World, and protect the S oul :pubkey enc packet: version 3, algo 1, keyid 506F4FA1D35FB186 data: [4095 bits] gpg: public key is D35FB186 You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded) ved...@nym.hush.com 4096-bit RSA key, ID D35FB186, created 2008-01-22 gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded) ved...@nym.hush.com 4096-bit RSA key, ID D35FB186, created 2008-01-22 gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: vedaal nistar (previous addresses were spam flooded)
Unusual (unintended?) behavor upon decryption of a message // follow-up correction
vedaal at nym.hush.com vedaal at nym.hush.com wrote onTue Nov 19 18:14:31 CET 2013 : gpg: public key decryption failed: bad passphrase gpg: encrypted with unknown algorithm 163 gpg: decryption failed: unknown cipher algorithm (the passphrase used was: 12345) Now here is the last part of the error message when a 'different incorrect' passphrase ( boo) is used: gpg: public key decryption failed: bad passphrase gpg: encrypted with unknown algorithm 231 gpg: decryption failed: unknown cipher algorithm The above happens 'only' on windows ( the box I used for Testing was Windows 7 Pro) and even then, doesn't happen on Cygwin. The error message on Ubuntu, or on Cygwin in Win 7 is just: gpg: decryption failed: unknown cipher algorithm This is still unusual, as gnupg already identified it as TWOFISH, not as an unknown algorithm, so the expected error message would be: decryption failed: bad passphrase vedaal vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
On 19/11/13 18:14, ved...@nym.hush.com wrote: Why does gnupg give these types of error message, as opposed to simply stating 'decryption failed: bad passphrase' ?? What kind of relationship is there between the number listed for the 'unknown algorithm' and the passphrase string that was given The passphrase is used to decrypt the concatenation of an octet specifying what cipher was used for the symmetrically-encrypted data packet and the key for that data packet. If you give the wrong passphrase, this comes out as random rubbish, and that first octet specifying the cipher for the data is rubbish as well. This is what GnuPG reports. There is no check if the decryption was succesful; it just results in garbage. After a few tens of tries, I suppose you can actually hit the case where the algorithm identifier is something usable, and GnuPG will probably try to decrypt the data packet with the rubbish it got from the symmetrically encrypted session key packet :). and might this be used in any way to try attack gnupg by determining the length of the passphrase or the correctness of any character in the string ? This line of reasoning is wrong. You are thinking of a system that knows the passphrase, and through its error messages, leaks data about it. But GnuPG knows as much as you. The security of the system is in the encrypted file, not in the program you use to access that file[1]. If GnuPG gave error messages that leaked data and this problem was fixed, you could simply write your own program that gives leaky error messages to you and use that to crack the key. Obviously it doesn't work that way. HTH, Peter. [1] Actually, DRM borders on exactly this: it gives you everything, but then tries to prevent your use of it. Which is why it has been called Broken By Design. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message // follow-up correction
On 19/11/13 20:47, ved...@nym.hush.com wrote: This is still unusual, as gnupg already identified it as TWOFISH, not as an unknown algorithm, TWOFISH was used to encrypt the session key. What was used to encrypt the data is still unknown, since that knowledge is encrypted. (With TWOFISH. Are you still following? ;P) There are potentially two symmetric ciphers at play, one to encrypt the session key, and one to encrypt the data. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://wwwhome.cs.utwente.nl/~lebbing/pubkey.txt ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
On 19-11-2013 7:07, Robert J. Hansen wrote: Even then, scrubbing data is usually a sign you've misunderstood the problem you're trying to solve. If you're concerned about sensitive data lurking on your hard drive the solution isn't to scrub the drive, it's to use an encrypted filesystem. That depends on your threat model. If you fear juridical problems (say, for example, some encrypted mails have been intercepted by the police but they can't decrypt them), destroying the key will prevent you from having to hand it over. In some jurisdictions this may be seen as contempt of court, and even be punishable, but in most EU countries you're safe when you do this. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
On 19/11/13 22:37, ved...@nym.hush.com wrote: But this isn't the way hybrid gnupg messages work. Gnupg does not use one symmetric algorithm to encrypt the session key, and then another to encrypt the message. The user can choose 'which' symmetric algorithm to use, but it will be the same for both. I only did a quick check of RFC 4880, and that (section 5.3) clearly states there is an octet for the symmetric algo used inside the encrypted part: The decryption result consists of a one-octet algorithm identifier that specifies the symmetric-key encryption algorithm used to encrypt the following Symmetrically Encrypted Data packet, followed by the session key octets themselves. So even if GnuPG always picks the same algo for both, the format of an OpenPGP message still separately specifies the algo for the data. My question is, is there oracle behavior on gnupg's part which will allow an attack on the string-to-key part of the symmetric encryption? If an attacker knows which symmetric algorithm was used, then concentrating of the first few characters of the passphrase, and trying variations of those, until gnupg identifies the correct algorithm, then gnupg may 'leak' the first few characters of the passphrase when the correct algorithm is identified, even if the message is not yet decrypted. How is this different from just writing your own implementation for decrypting the symmetrically-encrypted session key packet? Why would you abuse the GnuPG binary for this? The GnuPG binary doesn't provide the security, the encryption on the file does that. Furthermore, since the password is iteratively hashed with a salt, I don't think it would be possible to leak anything about the first few characters of the password. A hash evenly spreads all characters over the key (I'm oversimplifying a bit here). You just know the first octet of the plaintext of the symmetrically encrypted session key packet; the rest is utterly random. This is even a better situation than with Monthly results.doc.gpg where you probably know a lot of the header of a Microsoft Word document; it would be a lot easier to immediately attack the symmetrically-encrypted data than to first attack the session key packet and then try that on the data. When I say a lot easier, I still mean utterly impossible, though ;). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at http://digitalbrains.com/2012/openpgp-key-peter ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Unusual (unintended?) behavor upon decryption of a message // follow-up correction
If the message is encrypted to one public key, and also encrypted symmetrically instead of to a second public key, then the symmetric algorithm used by gnupg is the same for the encryption of the session key to the public key, as well as the session key to the symmetrically encrypted part, as well as the encryption of the plaintext. Sorry, was not writing clearly ;-(( Meant to say that the session key together with the prefix denoting which symmetric algorithm was used to encrypt the plaintext, is encrypted to the public key (using either RSA, DH, (or, hopefully soon, ECC), and also as a symmetrically encrypted packet containing the session key and identifying algorithm prefix, and then the symmetrically encrypted plaintext packet. These two latter symmetrically encrypted packets, while the could 'theoretically' be using two different symmetric algorithms, in fact use the same one, and that is the one identified as the algorithm used to encrypt the plaintext. Here is the PGP Dump results for the ciphertext I originally posted: PGPdump Results Old: Public-Key Encrypted Session Key Packet(tag 1)(524 bytes) New version(3) Key ID - 0x506F4FA1D35FB186 Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(4095 bits) - 5a 2d 7a e3 f9 99 af 2d 88 c1 ef 3b 8b 30 bf 94 d2 9f 68 ab 30 04 73 2e a2 7e 68 04 3a 00 6b 59 66 46 47 00 ec e8 6f e1 a8 40 5b b0 d9 87 ab a0 b2 23 4e 66 88 26 70 dc 74 d8 14 da 94 07 86 ce dd 48 37 0b cc d4 3d dd 5e b6 82 fb 04 47 13 fd fd b6 0c 7b 0e c2 c3 2b c8 1b c2 d4 e3 6b 68 85 85 b5 92 b2 1f c1 a7 1c ad f3 ed fb c3 2e 9e 4b a3 58 89 64 45 b1 b8 bb ba 7c 5b 2a 47 cd 42 d4 60 59 0b 9f 3a 16 1c 49 8d 92 ca d5 ba c4 fc 42 d1 56 bf 09 34 98 23 cf be 44 73 96 79 94 4b 55 6f 3d 8a bb f8 f1 4e b4 bd 94 0e 1f 1d 71 43 72 41 dc 7a b9 3e c2 5e 30 09 81 5e bf d6 e9 be e2 bd 85 a5 13 1a f1 31 d8 85 f0 07 ae 1a cc 4e cd aa d5 88 0c d8 51 83 ff 71 de cc d4 72 38 82 96 0a 0e d4 38 64 84 fe c7 a0 56 42 68 9b 04 88 79 cb 64 74 66 81 89 2c 41 d2 b1 2e af 31 5e 68 5e 20 79 c3 cc 13 30 55 16 8f 41 ca 16 56 fc 9c f8 07 7 c 64 7b 07 61 3a 44 f5 49 f1 51 4e 84 e8 4b 91 e3 9f ee f2 5c e0 5b 40 40 25 2f 13 39 d5 8a a8 60 ae c2 5a fa 2b 3b a5 c0 66 17 6f e7 cb bf 1f 37 da d8 28 71 90 74 35 f2 bb 85 8e 3b 3f a0 79 c7 43 ab a1 fb 4b 01 5a a9 ed 21 1a cd 1b 0f 1f fc 14 7e 3f f6 ae 30 1c 8a fb 2b ea d8 bc 63 98 84 6c 1e b5 48 0d 74 f4 da 7e 44 dd 5c 25 28 68 f9 46 c4 6d ed 39 b7 d4 73 85 2d 3f eb fe 17 21 c3 7e 42 7d a7 01 e2 b6 ce 4f 3b 83 f3 af e9 04 ef 5a 20 cc e6 de d7 6e dc af 64 f0 d9 52 62 ca 27 80 58 78 53 47 9f 53 da 95 d6 21 f6 f3 98 0d 7e 7b ec 8c 1d 47 5a 57 55 e0 cb 34 30 04 69 46 6d b8 b9 32 c0 1c 29 da 6b 37 c4 a0 79 24 d1 07 fd 55 77 d4 6b af 88 91 91 8a 0d b8 f4 c8 50 21 21 7f 5a 3a c5 d3 97 a4 12 63 2f a2 4f 5f 7b - m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02 Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(46 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 - 4d 55 b2 02 f0 1e e2 67 Count - 65536(coded count 96) Encrypted session key - sym alg(1 bytes) + session key New: Symmetrically Encrypted and MDC Packet(tag 18)(71 bytes) Ver 1 Encrypted data [sym alg is specified in sym-key encrypted session key] (plain text + MDC SHA1(20 bytes)) vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Unusual (unintended?) behavor upon decryption of a message
On Tuesday, November 19, 2013 at 3:02 PM, Peter Lebbing pe...@digitalbrains.com wrote: On 19/11/13 18:14, ved...@nym.hush.com wrote: Why does gnupg give these types of error message, as opposed to simply stating 'decryption failed: bad passphrase' ?? What kind of relationship is there between the number listed for the 'unknown algorithm' and the passphrase string that was given The passphrase is used to decrypt the concatenation of an octet specifying what cipher was used for the symmetrically-encrypted data packet and the key for that data packet. If you give the wrong passphrase, this comes out as random rubbish, and that first octet specifying the cipher for the data is rubbish as well. This is what GnuPG reports. There is no check if the decryption was succesful; it just results in garbage. After a few tens of tries, I suppose you can actually hit the case where the algorithm identifier is something usable, and GnuPG will probably try to decrypt the data packet with the rubbish it got from the symmetrically encrypted session key packet :). There are potentially two symmetric ciphers at play, one to encrypt the session key, and one to encrypt the data. = But this isn't the way hybrid gnupg messages work. If a message is encrypted to two different keys, gnupg will use the same symmetric algorithm to encrypt the session key to the public key, and also the plaintext to the ciphertext. If the message is encrypted to one public key, and also encrypted symmetrically instead of to a second public key, then the symmetric algorithm used by gnupg is the same for the encryption of the session key to the public key, as well as the session key to the symmetrically encrypted part, as well as the encryption of the plaintext. Gnupg does not use one symmetric algorithm to encrypt the session key, and then another to encrypt the message. The user can choose 'which' symmetric algorithm to use, but it will be the same for both. The symmetric algorithm is known, and is discoverable from gpg list-packets or from pgp-dump. My question is, is there oracle behavior on gnupg's part which will allow an attack on the string-to-key part of the symmetric encryption? If an attacker knows which symmetric algorithm was used, then concentrating of the first few characters of the passphrase, and trying variations of those, until gnupg identifies the correct algorithm, then gnupg may 'leak' the first few characters of the passphrase when the correct algorithm is identified, even if the message is not yet decrypted. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
On Tue, Nov 19, 2013 at 09:06:18PM +0100, Johan Wevers wrote: On 19-11-2013 7:07, Robert J. Hansen wrote: Even then, scrubbing data is usually a sign you've misunderstood the problem you're trying to solve. If you're concerned about sensitive data lurking on your hard drive the solution isn't to scrub the drive, it's to use an encrypted filesystem. That depends on your threat model. If you fear juridical problems (say, for example, some encrypted mails have been intercepted by the police but they can't decrypt them), destroying the key will prevent you from having to hand it over. In some jurisdictions this may be seen as contempt of court, and even be punishable, but in most EU countries you're safe when you do this. Especially knowing in most EU countries judges are not allowed to force you to hand over your secret key, only to decrypt specific messages for them. (Don't remember where I read that.) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
That depends on your threat model. If you fear juridical problems (say, for example, some encrypted mails have been intercepted by the police but they can't decrypt them), destroying the key will prevent you from having to hand it over. In some jurisdictions this may be seen as contempt of court, and even be punishable, but in most EU countries you're safe when you do this. Especially knowing in most EU countries judges are not allowed to force you to hand over your secret key, only to decrypt specific messages for them. (Don't remember where I read that.) Most encrypted drive software doesn't actually work the way people seem to think they work. The drive is encrypted with a random nonce. This nonce is written to disk in an encrypted format. When you enter a passphrase to unlock the drive, the encrypted random nonce is read in and decrypted using the passphrase. The newly-recovered random nonce is then used to do all further crypto operations. To put the data forever beyond recovery, you generate a new nonce, encrypt it with the same passphrase, and write it over the old nonce. If someone demands your cryptographic key you can honestly and genuinely give it up without any fear of your old data being compromised. The investigator will be able to verify that you've complied with the court's order, and the investigator will also be able to verify that you never knew the original nonce. This drive was originally encrypted with a random nonce which the defendant never knew. The defendant cannot be compelled to produce information the defendant never possessed. This random nonce is irretrievably gone. The defendant *can* be compelled to produce the key used to encrypt that random nonce, and the defendant seems to have complied with that order -- but the random nonce itself is gone, and with it, any hope of recovering the data on the encrypted drive. I cannot think of a single use case for scrubbing plaintext storage devices. In every use case I can come up with, the user would be better served by using an encrypted storage device. That doesn't mean no such use case exists, mind you -- just that I can't think of one. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
On 11/19/2013 3:50 PM, Robert J. Hansen wrote: [...] then used to do all further crypto operations. To put the data forever beyond recovery, you generate a new nonce, encrypt it with the same passphrase, and write it over the old nonce. If someone demands your cryptographic key you can honestly and genuinely give it up without any fear of your old data being compromised. The investigator will be able to verify that you've complied with the court's order, and the investigator will also be able to verify that you never knew the original nonce. I'd be surprised if this gets you very far in a US court. Technical details aside, what the court will likely see is that you deliberately took action intended to put the data beyond the reach of the court in order to avoid whatever legal ramifications that access might have. The results of that will probably not be very good (US judges have quite broad powers when it comes to contempt of court). -C signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
On Tue, Nov 19, 2013 at 02:50:20PM -0800, Robert J. Hansen wrote: That depends on your threat model. If you fear juridical problems (say, for example, some encrypted mails have been intercepted by the police but they can't decrypt them), destroying the key will prevent you from having to hand it over. In some jurisdictions this may be seen as contempt of court, and even be punishable, but in most EU countries you're safe when you do this. Especially knowing in most EU countries judges are not allowed to force you to hand over your secret key, only to decrypt specific messages for them. (Don't remember where I read that.) Most encrypted drive software doesn't actually work the way people seem to think they work. The drive is encrypted with a random nonce. [...] Actually, I answered the encrypted mails part. Thanks anyway. I cannot think of a single use case for scrubbing plaintext storage devices. In every use case I can come up with, the user would be better served by using an encrypted storage device. That doesn't mean no such use case exists, mind you -- just that I can't think of one. Well... I can see one : the user used a plaintext storage device without thinking about it, and then understands he needs an encrypted device and scrubs his hard drive when the encrypted drive is set up with the necessary information. Another one would be (paranoid) fear about the long long term : who knows some three-letter agency would not steal your computer, and store its hard drive content until decryption is available (say, 10 years from now, being quite optimistic?). So scrubbing the already-encrypted data would help ensure data is never recovered. Maybe scrubbing a specific file, without need to reset files on full blocks, block-based encryption being AFAICT the most frequent way of encrypting complete hard drives. That's all I can figure out. Cheers, Leo ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: article about Air Gapped OpenPGP Key
On 11/19/2013 6:03 PM, Chris De Young wrote: I'd be surprised if this gets you very far in a US court. Depends on when you did it and why. Many businesses have document retention policies (crafted with the assistance of counsel) that specify old documents are to be put beyond recovery, and scrapping a crypto key is generally seen as more cost-effective than shipping the drive off to be shredded. IronMountain charges $X per drive, but wiping a crypto key is effectively free. If you do this in response to an investigation then yes, you're likely going to make the judge very unhappy. If you do this as part of normal business practices that were devised with the assistance of counsel, you're likely to fare much better. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
