[cygwin] gpg-agent with ssh support ?
Hi all, On my workstation, I have installed cygwin and GPG4win which is bundled with a version of gpg-agent (cygwin comes whith oldies and no gpg-agent AFAICS). I enabled ssh support in the gpg-agent.conf file as usual and I clearly see the socket files for both GNUpg and SSH. When starting a cygwin terminal and trying to decrypt one file using gpg --decrypt file.gpg, pinentry comes in and asks for my passphrase (and then cache it into gpg-agent). On the other hand, trying to add an identify file into the agent fails. It tells it can't connect to the agent. In fact, after hours of trial and errors, I gave up launching ssh-agent manually. Do you know a way to fix that and only use gpg-agent as my sole agent entry point for both gpg and ssh ? Regards -- Xavier. pgpAlX8HdwmSy.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trezor - Could this be the model for a PGP crypto device?
On 03/10/2015 09:18 PM, Jonathan Schleifer wrote: > Does this really need to be part of the specification? For example, > the Gnuk could just delay signing / decryption / authentication > until the button has been pressed and return an error if it doesn't > get pressed within a certain amount of time. Good point. Yes, it is possible to implement "ack" button in a way you describe. But, technically, it's not good for the underlying layer to impose this kind of "snatch". It is better for Host PC to know the interaction. Besides, when possible, I don't want a feature to be implemented only for Gnuk. I don't want to differentiate, but to collaborate. Well, I realized that my idea of yesterday was not good. According to ISO 7816-4, no command is allowed before GET RESPONSE. So, we could consider something like this: Host PC OpenPGPcard command: PSO => <= response: 0x9F command: VERIFY with 0x84 ==> (or something different than 0x81, 0x82, or 0x83) <= response: 0x9000 OK command: GET DATA on some pseudo Data Object ==> <= response: of result of PSO It seems for me that we can use 0x9F to let host PC the length of data. (while 0x61 expects succeeding GET RESPONSE.) This can be done with smartcard + cardreader with pinpad. -- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 20:33, maricelgregorasc...@yahoo.com said: > I admit I haven't looked at the AES-NI instruction set, but I've read > that it could be easy for the CPU to reconstruct the key from a Possible. It is also easy to detect the instructions used for software based AES keyscheduling and leak the key from that knowledge. I'd pick AES-NI for its better performace and SCA resistance. RDRAND for random numbers is a different story. No sane crypto tool should soley rely on this instruction. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote: > Pete, > Very useful info about using --show-session-key to avoid revealing your > private asymmetric key. No worries. > In your example ("gpg --show-session-key < example.txt") , had you > somehow set up gpg to use symmetric by default, rather than asymmetric + > symmetric? No. It was a nearly "out of the box" setup with only some minor changes to my gpg.conf file in regards to accessing keyservers. Nothing that would affect the modes of encryption. > If I explicitly pass --symmetric, --show-session-key does nothing > (gpg4win) (and I guess the key is not really a random "session" key as > when sending a PGP message) but rather the key deterministically > generated from the passphrase. Works fine for me. Try copy-pasting the text into the command prompt rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG you're done entering a message and it should start processing things. Here's an encrypted message I generated with "gpg --symmetric --armor" on GPG4Win 2.2.3: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB cC6eqAI= =j73k -END PGP MESSAGE- (password is "test" with no quotes) gpg --show-session-key yields a session key of "3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F". The same message encrypted a few seconds later with the same password yields: -BEGIN PGP MESSAGE- Version: GnuPG v2 jA0EAwMCgnIlCp86aLq1ySQt2veDYta5U1uxPiust4siTyduBe7+CVhupax2HKeI Zcm3Rx0= =kZPs -END PGP MESSAGE- and a session key of "3:A81A96428D44DEAD3A6079CC22145B51 It appears that GnuPG uses the iterated-and-salted secret-to-key method (see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate the session key. You're right: the key is derived from a passphrase and so is not truly random, but the salt is random which helps a bit. Of course, the salt is not encrypted, so the message protection depends only on the strength of your passphrase. > I agree, using key instead of passphrase doesn't enhance security > (assuming an attacker knows that the key was derived from a passphrase > and with what key derivation algorithm? I assume the randomness/entropy > of the key itself is high enough regardless of the passphrase strength?). The attacker would be able determine quite a bit of information about how the message was encrypted (as this same information would be needed by a legitimate user to decrypt the message): Here's an excerpt from the double-verbose (-vv) output from the second encrypted message above (all this is available without entering the passphrase): :symkey enc packet: version 4, cipher 3, s2k 3, hash 2 salt 8272250a9f3a68ba, count 2752512 (181) The attacker would know the cipher being used (cipher 3 = CAST5), the fact that the key is derived from a user-provided string (the fact that s2k is used), which string-to-key algorithm is used (s2k 3 = iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the number of times to iterate the S2K algorithm. The attacker won't know the strength of your passphrase -- it could be "cat" or a long string of random characters -- but it tells them that the key was generated using user-provided input. > The reason I was asking if it's a possibility to store the symmetric key > to decrypt with later, was to protect against future changes in the key > derivation algorithm, that would make gpg generate a different key for > the same passphrase, useless to decrypt previously encrypted data. GnuPG follows the OpenPGP standard (RFC 4880). The standard defines certain key derivation algorithms and provides the ability to add new ones if needed. Adding new key derivation algorithms in the future should not have any affect on existing encrypted messages. Since each message clearly identifies the algorithm used to encrypt it, future versions of GnuPG should have no problem decrypting it. Indeed, the current version of GnuPG is able to decrypt messages generated from old (even ancient!) versions of PGP and GnuPG with few, if any, issues. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 20:39, maricelgregorasc...@yahoo.com said: > Thanks Werner.On Windows, you mean on each drive letter, in the root > directory? (e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be Yes, that was the idea. The file names should however be c:\etc\gcrypt\hwf.deny d:\etc\gcrypt\hwf.deny I have not tested this. > a way to make gpg display which hardware features are being used when > encrypting/decrypting (to confirm that the deny file was correctly > placed and actually had an effect)? Thank you. From: Werner Koch Not yet. 2.1.3 will have a command to list it. You may simply encrypt a large file and compare the times. It is way faster with AES-NI enabled. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/10/2015 at 4:19 PM, "Maricel Gregoraschko" wrote: >I agree, using key instead of passphrase doesn't enhance security >(assuming an attacker knows that the key was derived from a >passphrase and with what key derivation algorithm? I assume the >randomness/entropy of the key itself is high enough regardless of >the passphrase strength?). The reason I was asking if it's a >possibility to store the symmetric key to decrypt with later, was >to protect against future changes in the key derivation algorithm, >that would make gpg generate a different key for the same >passphrase, useless to decrypt previously encrypted data.Thank you >for your support. - If you don't want to keep your passsphrase, and want only to keep the session key, and you want this to have no weakness because of a questionably strong enough password that was used to generate the key, then there is an easy way to do what you want: [1] Encrypt a test message to any of your own keys. [2] Decrypt this test message, with the option of --show-session-key [3] Use this session key as the 64 character password for your symmetric encryption, (and save it, or you won't be able to decrypt the symmetric message). [4] Decrypt your symmetrically encrypted file or message, using the option of --show-session-key [5] Save this session key, and if you wish, you can destroy the first one. (you can always get it back by decrypting your message of step [1] ). The string-to-key part of generating the session key for the symmetrically encrypted message, will be using a random 64 character GnuPG generated session key as it's password. You can't find a better password (especially even one that you don't have to remember ;-) ) vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Thanks Werner.On Windows, you mean on each drive letter, in the root directory? (e.g. c:\hwf.deny, d:\hwf.deny, etc.?).Also would there be a way to make gpg display which hardware features are being used when encrypting/decrypting (to confirm that the deny file was correctly placed and actually had an effect)? Thank you. From: Werner Koch To: Andre Heinecke Cc: gnupg-users@gnupg.org; Maricel Gregoraschko Sent: Tuesday, March 10, 2015 10:58 AM Subject: Re: AES-NI, symmetric key generation On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said: >> Also is there any >> option to turn hardware acceleration on or off at runtime? You can globally disable certain hardware features: Create a file --8<---cut here---start->8--- # We do not want to use AES-NI intel-aesni --8<---cut here---end--->8--- and store it as /etc/gcrypt/hwf.deny . This should work also on Windows if you copy that file to every drive. The list of hardware features in the current development version is: { HWF_PADLOCK_RNG, "padlock-rng" }, { HWF_PADLOCK_AES, "padlock-aes" }, { HWF_PADLOCK_SHA, "padlock-sha" }, { HWF_PADLOCK_MMUL,"padlock-mmul"}, { HWF_INTEL_CPU, "intel-cpu" }, { HWF_INTEL_BMI2, "intel-bmi2" }, { HWF_INTEL_SSSE3, "intel-ssse3" }, { HWF_INTEL_PCLMUL,"intel-pclmul" }, { HWF_INTEL_AESNI, "intel-aesni" }, { HWF_INTEL_RDRAND,"intel-rdrand" }, { HWF_INTEL_AVX, "intel-avx" }, { HWF_INTEL_AVX2, "intel-avx2" }, { HWF_ARM_NEON, "arm-neon" } Libgcrypt 1.6 has less features. BTW, I just pushed a change for 2.1 to show the used Libgcrypt configuration: --8<---cut here---start->8--- $ gpg --list-gcrypt-config version:1.6.3-beta12: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: threads:none: hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx: fips-mode:n:n: rng-type:standard:1: --8<---cut here---end--->8--- Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
> AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. I admit I haven't looked at the AES-NI instruction set, but I've read that it could be easy for the CPU to reconstruct the key from a sequence of calls typical to AES encryption/decryption (I think implementations even use Intel-provided code), and store it for later retrieval through a secret CPU instruction set. From: Andre Heinecke To: gnupg-users@gnupg.org; Maricel Gregoraschko Sent: Tuesday, March 10, 2015 5:05 AM Subject: Re: AES-NI, symmetric key generation Hi, To answer your first question regarding gpg4win: On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote: > Hello All,I would first like to thank you for your effort and time > developing gnupgp.I have a couple of questions: 1. Does GnuGP (in > particular, the Windows binaries distributed for gpg4win) use AES-NI, the > Intel dedicated AES instruction set? No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track this. > There are some concerns, I'm not sure > how realistic, about backdoors built into the CPU themselves. AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. > I noticed > there is an option to "configure", --disable-aesni-support. Where can I get > the full configure command as it was used to build the posted gpg4win > binaries, to check if that switch was present or not? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am Look for gpg4win_pkg__configure (e.g. gpg4win_pkg_libgcrypt_configure) > Also is there any > option to turn hardware acceleration on or off at runtime? No. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Pete,Very useful info about using --show-session-key to avoid revealing your private asymmetric key.In your example ("gpg --show-session-key < example.txt") , had you somehow set up gpg to use symmetric by default, rather than asymmetric + symmetric?If I explicitly pass --symmetric, --show-session-key does nothing (gpg4win) (and I guess the key is not really a random "session" key as when sending a PGP message) but rather the key deterministically generated from the passphrase. I agree, using key instead of passphrase doesn't enhance security (assuming an attacker knows that the key was derived from a passphrase and with what key derivation algorithm? I assume the randomness/entropy of the key itself is high enough regardless of the passphrase strength?). The reason I was asking if it's a possibility to store the symmetric key to decrypt with later, was to protect against future changes in the key derivation algorithm, that would make gpg generate a different key for the same passphrase, useless to decrypt previously encrypted data.Thank you for your support. From: Pete Stephenson To: Maricel Gregoraschko Cc: gnupg-users@gnupg.org Sent: Tuesday, March 10, 2015 10:36 AM Subject: Re: AES-NI, symmetric key generation On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote: > Hello All, Hi! > 2. When using symmetric encryption and providing a passphrase, I > understand the actual encryption key is generated on the spot, used to > do the encryption, and then discarded from memory and not stored > anywhere, is that correct? Correct. > If the user wanted, can they dump the encryption key to store it > securely, and use it to decrypt, instead of the password? Yes, but the security is only as strong as the weakest link: if one uses a weak passphrase to encrypt a message, an adversary could guess the password. If one used a long random string as a passphrase, this is functionally equivalent to a strong key, so why bother with using the key itself to decrypt instead of the passphrase? You can show the symmetric session key for a message using the "--show-session-key" option. Here's an example of text I encrypted with "gpg --symmetric": -BEGIN PGP MESSAGE- Version: GnuPG v1 jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8 B8SW2A== =Iz40 -END PGP MESSAGE- The passphrase is "test" (no quotes). pete@kaylee:~$ gpg --show-session-key < example.txt [prompt for password] gpg: CAST5 encrypted data gpg: gpg-agent is not available in this session gpg: encrypted with 1 passphrase gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF' gpg: example.txt: unknown suffix Later, I can use gpg with the "--override-session-key" option to supply the decryption key directly. Use "gpg --override-session-key [session key]", using the format given above: pete@kaylee:~$ gpg --override-session-key 3:62A2421F805F6CB1767A9DF07983ADDF < example.txt gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase Hello world! gpg: WARNING: message was not integrity protected See the manpage or https://www.gnupg.org/documentation/manpage.html for more details. One interesting note about show/override-session-key: if one is compelled to decrypt a message (or else...), one can use those options on messages encrypted using GnuPG's symmetric or the more usual asymmetric (i.e., public key) encryption methods. The manpage says, "This option is normally not used but comes handy in case someone forces you to reveal the content of an encrypted message; using this option you can do this without handing out the secret key." In other words, if you're compelled to decrypt a message that was encrypted to your public key, you don't need to hand over your private key (which would allow someone to decrypt all your messages, sign new messages, etc.). Instead, you would just hand over the encrypted message and the session key used to encrypt it. Since each message uses a new, random session key, only that single message can be decrypted and your private key is not compromised. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
GnuPG News for February 2015
Hi! Find below the plain text version of https://gnupg.org/blog/20150310-gnupg-in-february.html Shalom-Salam, Werner 1 GnuPG News for February 2015 ══ Indeed, very exiting news this month: The financial crisis of The GnuPG Project is over. Due to an unexpected amount of donations received in the first days of February we can keep on working for at least the next 2 or 3 years. How did this happen? At the [31C3] Nico Josattis arranged an Interview with [Julia Angwin] who writes for [ProPublica]. Eventually on the 5th her [article] was published and immediately received a lot of attention. Not only at the ProPublica site but at many other news site as well. While checking my mail on that evening, I noticed more than thousand notification mails for donations and even better: that continuous stream of donations did not stop for the next days. Alone on the first day we received more than 120,000 € and thus more than our initial goal. I even had to fix the script building the donation progress bar to not overflow the right margin the same night. I also received a call from one of the Stripe founders who offered yearly donations from Stripe and Facebook each at 50, $. Amazing. I like to *thank everyone* for supporting the project, be it small or large individual donations, helping users, providing corporate sponsorship, working on the software, and for all the encouraging words by mail, blogs, and even postcards. Due to that new publicity for GnuPG, I received many requests for interviews and for several days journalists and photographers visited me in my office. They wrote several articles for German papers and radio stations, for example in the [taz], the [Süddeutsche Zeitung], and the [Deutsche Welle]. I hope these articles help to keep up the awareness for the importance of privacy issues. GnuPG does not stand alone: there are many other projects, often unknown to most people, which are essential to keep the free Internet running. Many of them are run by volunteers who spend a lot of unpaid time on them. They need our support as well! Now what to do with all that money? Before a final plan can be drafted, tax issues need to be resolved. Given that g10^code (the legal entity behind the project) is not a charity, we need to find a way to stretch the use of the money beyond this year. My tax advisor is currently looking into this and I will report on the outcome in another blog entry. Regardless of this I started to look out for a second developer and fortunately [Neal Walfield] was searching for a job and accepted my offer to work on GnuPG. Neal is well known for his work on modern operating systems and I consider him an excellent hacker. I am glad to have him on board. [31C3] https://events.ccc.de/congress/2014/wiki/Main_Page [Julia Angwin] http://juliaangwin.com [ProPublica] http://www.propublica.org [article] http://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-broke [taz] http://www.taz.de/Verschluesselung-mit-GnuPG/!154635/ [Süddeutsche Zeitung] http://www.sueddeutsche.de/digital/verschluesselungssoftware-gnu-pg-wie-ein-mann-das-e-mail-geheimnis-verteidigt-1.2355155 [Deutsche Welle] http://dw.de/p/1Eebj [Neal Walfield] http://walfield.org 1.1 Release status ── GnuPG [2.1.2] was released on the 11th, [2.0.27] on the 18th, and [1.4.19] on the 27th. The 1.4.19 release features a fix for a new side channel attack on the Elgamal encryption (which used to be the default public key encryption algorithm until 2009). Go ahead and read how Genkin’s group describes the [details] of this attack. The release also includes a mitigation for another SCA to be described in the forthcoming paper /Last-Level Cache Side-Channel Attacks are Practical/ by Yarom et al. Libgcrypt [1.6.3] was released on the 27th to fix the described SCAs for GnuPG 2.0 and 2.1. [2.1.2] https://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000361.html [2.0.27] http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000362.html [1.4.19] http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000363.html [details] http://www.cs.tau.ac.il/~tromer/radioexp/ [1.6.3] http://lists.gnupg.org/pipermail/gnupg-announce/2015q1/000364.html 1.2 Released and not yet released changes ─ Several segfaults due to NULL-derefs and invalid memory reads when using garbled keyrings were fixed. These unlikely exploitable bugs were detected by fuzzing instrumented versions of GnuPG; [Hanno Böck's report] has some details. A long standing implementation flaw copying memory stored values to integers variables was also found and fixed. These bug fixes have been backported to 2.0 and 1.4; Daniel Kahn Gillmor was kind enou
Re: Suggestions for a Practical Scheme to Manage Multiple Identities?
On 10.03.15 04:41, NIIBE Yutaka wrote: >> So this is not a question about portable flash drives vs. smartcards per >> > se. I _think_ I understand those risks and trade-offs but if there is >> > something I'm missing then, of course, I'd like to know. > I had an experience that one of my family members took my portable > flash drive for his/her own purpose (and it took hours/days for me to > realize the fact). > > This might be another risk. On top of all the other problems of a general purpose storage device. I'd say just go with a smartcard or purpose built token device [1][2]. As for the multiple identities, different smartcards as needed. That makes the reader the only device to carry and the cards you can cut (some precut) to SIM-card size to make carrying easy. And there are small readers available. [1]: http://www.seeedstudio.com/wiki/index.php?title=FST-01 [2]: http://www.fsij.org/doc-gnuk/ -- Ville signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote: > Hello All, Hi! > 2. When using symmetric encryption and providing a passphrase, I > understand the actual encryption key is generated on the spot, used to > do the encryption, and then discarded from memory and not stored > anywhere, is that correct? Correct. > If the user wanted, can they dump the encryption key to store it > securely, and use it to decrypt, instead of the password? Yes, but the security is only as strong as the weakest link: if one uses a weak passphrase to encrypt a message, an adversary could guess the password. If one used a long random string as a passphrase, this is functionally equivalent to a strong key, so why bother with using the key itself to decrypt instead of the passphrase? You can show the symmetric session key for a message using the "--show-session-key" option. Here's an example of text I encrypted with "gpg --symmetric": -BEGIN PGP MESSAGE- Version: GnuPG v1 jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8 B8SW2A== =Iz40 -END PGP MESSAGE- The passphrase is "test" (no quotes). pete@kaylee:~$ gpg --show-session-key < example.txt [prompt for password] gpg: CAST5 encrypted data gpg: gpg-agent is not available in this session gpg: encrypted with 1 passphrase gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF' gpg: example.txt: unknown suffix Later, I can use gpg with the "--override-session-key" option to supply the decryption key directly. Use "gpg --override-session-key [session key]", using the format given above: pete@kaylee:~$ gpg --override-session-key 3:62A2421F805F6CB1767A9DF07983ADDF < example.txt gpg: CAST5 encrypted data gpg: encrypted with 1 passphrase Hello world! gpg: WARNING: message was not integrity protected See the manpage or https://www.gnupg.org/documentation/manpage.html for more details. One interesting note about show/override-session-key: if one is compelled to decrypt a message (or else...), one can use those options on messages encrypted using GnuPG's symmetric or the more usual asymmetric (i.e., public key) encryption methods. The manpage says, "This option is normally not used but comes handy in case someone forces you to reveal the content of an encrypted message; using this option you can do this without handing out the secret key." In other words, if you're compelled to decrypt a message that was encrypted to your public key, you don't need to hand over your private key (which would allow someone to decrypt all your messages, sign new messages, etc.). Instead, you would just hand over the encrypted message and the session key used to encrypt it. Since each message uses a new, random session key, only that single message can be decrypted and your private key is not compromised. Cheers! -Pete ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
On Tue, 10 Mar 2015 10:05, aheine...@intevation.de said: >> Also is there any >> option to turn hardware acceleration on or off at runtime? You can globally disable certain hardware features: Create a file --8<---cut here---start->8--- # We do not want to use AES-NI intel-aesni --8<---cut here---end--->8--- and store it as /etc/gcrypt/hwf.deny . This should work also on Windows if you copy that file to every drive. The list of hardware features in the current development version is: { HWF_PADLOCK_RNG, "padlock-rng" }, { HWF_PADLOCK_AES, "padlock-aes" }, { HWF_PADLOCK_SHA, "padlock-sha" }, { HWF_PADLOCK_MMUL,"padlock-mmul"}, { HWF_INTEL_CPU, "intel-cpu" }, { HWF_INTEL_BMI2, "intel-bmi2" }, { HWF_INTEL_SSSE3, "intel-ssse3" }, { HWF_INTEL_PCLMUL,"intel-pclmul" }, { HWF_INTEL_AESNI, "intel-aesni" }, { HWF_INTEL_RDRAND,"intel-rdrand" }, { HWF_INTEL_AVX, "intel-avx" }, { HWF_INTEL_AVX2, "intel-avx2" }, { HWF_ARM_NEON,"arm-neon" } Libgcrypt 1.6 has less features. BTW, I just pushed a change for 2.1 to show the used Libgcrypt configuration: --8<---cut here---start->8--- $ gpg --list-gcrypt-config version:1.6.3-beta12: ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147: pubkeys:dsa:elgamal:rsa:ecc: digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog: rnd-mod:linux: cpu-arch:x86: mpi-asm:amd64/mpih-add1.S:amd64/mpih-sub1.S:amd64/mpih-mul1.S:amd64/mpih-mul2.S:amd64/mpih-mul3.S:amd64/mpih-lshift.S:amd64/mpih-rshift.S: threads:none: hwflist:intel-cpu:intel-ssse3:intel-pclmul:intel-aesni:intel-avx: fips-mode:n:n: rng-type:standard:1: --8<---cut here---end--->8--- Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg in a cybercafé
On Thu, 05 Mar 2015 22:27:36 +, flapflap wrote: > The current version (1.3) of Tails comes with GnuPG 1.4.12. That's just not true. Not only is the gpg2 command available, but the change log even explicitly states that GnuPG 2 was added to improve smartcard support. -- Jonathan pgpMrNu2rjlQA.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Trezor - Could this be the model for a PGP crypto device?
On Tue, 10 Mar 2015 13:35:27 +0900, NIIBE Yutaka wrote: > Confirmation push button would be a good idea, and I have been > considering how we can enhance the OpenPGPcard specification so that > we could do something like that for future implementation(s). Does this really need to be part of the specification? For example, the Gnuk could just delay signing / decryption / authentication until the button has been pressed and return an error if it doesn't get pressed within a certain amount of time. -- Jonathan pgpoQTbUc54_Z.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: GPG4Win 2.2.3 Smart card support
On Tue, 10 Mar 2015 08:14, deepak.sax...@safenet-inc.com said: > I am trying to test file encryption with SafeNet smart cards. (CardOs/ Java > and other tokens). > I am getting error message: The card application is not yet supported. You need to write an application which GnuPG knows about. The source files scd/app-*.c implement the hist part of the card applictions. If you card has a pkcs#15 structure it would be used, if not you need to provide the specifications for the card and write such an application driver or find someone who is interested in doing that. You may however use the card directly sending the respecive APDUs to the card. You can test this with gpg-connect-agent; use scd serialno undefined to convince scdaemon to use the card without any known application and then run scd help apdu to learn about the APDU command. > I can see the list of supported tokens as: > https://wiki.debian.org/GnuPG/CCID_Driver This is a lower layer. On Windows pkcs@11 is used and AFAICS it works for you. Salam-Shalom, Werner p.s. > The information contained in this electronic mail transmission > may be privileged and confidential, and therefore, protected > from disclosure. If you have received this communication in > error, please notify us immediately by replying to this Did the GCHQ complied with that request when they grabbed all those SIM card keys? ;-) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AES-NI, symmetric key generation
Hi, To answer your first question regarding gpg4win: On Monday, March 09, 2015 05:15:14 PM Maricel Gregoraschko wrote: > Hello All,I would first like to thank you for your effort and time > developing gnupgp.I have a couple of questions: 1. Does GnuGP (in > particular, the Windows binaries distributed for gpg4win) use AES-NI, the > Intel dedicated AES instruction set? No, it has been disabled due to a bug. I've opened gnupg/issue1919 to track this. > There are some concerns, I'm not sure > how realistic, about backdoors built into the CPU themselves. AES is an algorithm that produces deterministic results. Not really something to backdoor like a RNG. > I noticed > there is an option to "configure", --disable-aesni-support. Where can I get > the full configure command as it was used to build the posted gpg4win > binaries, to check if that switch was present or not? http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpg4win.git;a=blob;f=src/Makefile.am Look for gpg4win_pkg__configure (e.g. gpg4win_pkg_libgcrypt_configure) > Also is there any > option to turn hardware acceleration on or off at runtime? No. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
RE: GPG4Win 2.2.3 Smart card support
Hi Yutaka, I am trying to test file encryption with SafeNet smart cards. (CardOs/ Java and other tokens). I am getting error message: The card application is not yet supported. I have dll libraries for my tokens but I am new to GPG4Win. Can you please guide me the way to import the library or steps by how can I configure GPG4win to support these tokens/ smartcards. I can see the list of supported tokens as: https://wiki.debian.org/GnuPG/CCID_Driver It it anyhow possible to support other tokens?? -Original Message- From: NIIBE Yutaka [mailto:gni...@fsij.org] Sent: Tuesday, March 10, 2015 11:16 AM To: Saxena, Deepak Cc: gnupg-users@gnupg.org Subject: Re: GPG4Win 2.2.3 Smart card support Hello, This is second time for me to receive the message like: > The information contained in this electronic mail transmission may be > privileged and confidential, and therefore, protected from disclosure. > If you have received this communication in error, please notify us > immediately by replying to this message and deleting it from your > computer without copying or disclosing it. I can't answer to a message saying like this. Perhaps, so can't everyone (and that would be the reason why you didn't get reply). Thus, this is not the reply, but a monologue of mine. In January, I wrote a message to this list: https://lists.gnupg.org/pipermail/gnupg-users/2015-January/052298.html It may help somehow, but it should be just a coincidence. -- The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users