Re: ECC curves used in gnupg?
On Tue, 2013-12-17 at 13:01 -0600, Anthony Papillion wrote: I know that gnupg is experimenting with ECC and I'm wondering which curves the team has decided to use. I know there are some curves that are now suspected of being tainted by the NSA through NIST. Has the gnupg team ruled using those curves out? Wouldn't it be nice to include ecc curves up to 1024 bit(ecc brainpool gives you 512 bit at most, maryland 521). I calculated the parameters last year(no ties to maryland) and they are free for noncommercial use ;-) They can be found here: http://www.fh-wedel.de/~an/crypto/accessories/domains_anders.html In the ECC software Academic Signature -which contains a minimalistic GnuPG GUI by the way- you can check their sanity, including the MOV condition. There has been a thread on insecure GnuPG defaults lately. (SHA1 h) Please keep in mind that (to my knowledge) maryland does allow the export of ecc software up to 256 bit if in the interest of national security. So why not exclude bit sizes smaller than 256 from the very beginning. regards Michael ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: ECC curves used in gnupg?
On Tue, 17 Dec 2013 20:01, anth...@cajuntechie.org said: I know that gnupg is experimenting with ECC and I'm wondering which curves the team has decided to use. I know there are some curves that are now suspected of being tainted by the NSA through NIST. Has the gnupg team ruled using those curves out? We will support the curves specified in RFC-6637. These are the NIST curves P-256, P-384, and P-521. I recently added support for Brainpool P256r1, P384r1, and P512r1 to make some some European governments happy. I the wake of recent events and due to the fear of many people that the NIST curves might have some secret properties, I added support for Bernstein et al's Ed25519 signature scheme. The problem here is that it is not really covered by RFC-6637 because it does not use the ECDSA signature scheme but a Schnorr like scheme named EdDSA. Thus for a proper implementation we need to assign a new algorithm number to it which in turn means to write another RFC. I recently met with Phil Zimmermann and we talked about the OpenPGP future. It is pretty clear that we need to replace the current algorithms with elliptic curves to get a better security margin for the future. Alhough there are no technical reasons not to use existing standard curves, we better take the users unhappiness with NIS curves in account and move on to curves like Ed25519 which are easier to use and are an outcome of public research. Bernstein and Lange are currently working on a 384 bit curve and it is very likely that this one will also be added to GnuPG. 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
gpgsm, certificate expired, different certificate, epa does not encrypt
Hello I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. I have several email accounts with different (comodo certificates). Now one certificate for the address addre...@gmail.com has expired. However I want to send an email from address2 (whose certificate is *not* expired) to a recipient. However when I try to encrypt this message, it does not work. I obtain an error message, whose epa bug trace I attach. It is not clear to me, who is the culprit, epa or gpgsm. But I consider this is a BUG, I don't want to use the expired certificate but one which is not expired. thanks Uwe Brauer gpgsm --no-tty --status-fd 1 --yes --output /tmp/oub/epg-outputR_HIIF --detach-sign -u F69E1EFB6147C786 gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: certificate has expired gpgsm: (expired at 2013-12-16 23:59:59) gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: NOTE: won't be able to encrypt to `burr...@gmail.com': Certificate expired gpgsm: DBG: adding certificates at level -1 [GNUPG:] SIG_CREATED D 1 2 00 20131218T101015 AF791B3AE3CCA0A1A9575730F69E1EFB6147C786 gpgsm: signature created gpgsm --no-tty --status-fd 1 --yes --output /tmp/oub/epg-outputR_HVSL --encrypt -r 768D0C6F306269A7 -r F69E1EFB6147C786 gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: certificate has expired gpgsm: (expired at 2013-12-16 23:59:59) gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: can't encrypt to `burr...@gmail.com': Certificate expired [GNUPG:] INV_RECP 5 burr...@gmail.com gpgsm --no-tty --status-fd 1 --yes --output /tmp/oub/epg-outputR_HicR --detach-sign -u F69E1EFB6147C786 gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: certificate has expired gpgsm: (expired at 2013-12-16 23:59:59) gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: NOTE: won't be able to encrypt to `burr...@gmail.com': Certificate expired gpgsm: DBG: adding certificates at level -1 [GNUPG:] SIG_CREATED D 1 2 00 20131218T101051 AF791B3AE3CCA0A1A9575730F69E1EFB6147C786 gpgsm: signature created gpgsm --no-tty --status-fd 1 --yes --output /tmp/oub/epg-outputR_HvmX --encrypt -r F69E1EFB6147C786 -r F69E1EFB6147C786 gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: certificate has expired gpgsm: (expired at 2013-12-16 23:59:59) gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: note: non-critical certificate policy not allowed gpgsm: CRLs not checked due to --disable-crl-checks option gpgsm: can't encrypt to `burr...@gmail.com': Certificate expired [GNUPG:] INV_RECP 5 burr...@gmail.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encryption algorithm
On Wed, 18 Dec 2013 02:27, r...@sixdemonbag.org said: because you just shifted to arguing that since GnuPG defaults to AES-256, we need to use RSA-15000 by default otherwise the asymmetric FWIW: The rationale why we use the order AES256,192,128 is for compatibility reasons with PGP. If gpg would define AES128 first, we would get the somewhat confusing situation: gpg -r pgpkey -r gpgkey ---gives-- AES256 gpg -r gpgkey -r pgpkey ---gives-- AES PGP prefers AES256 for the simple reason that the marketing deptartment told the engineering that 256 sounds stronger than 128 (according to one of their lead developers). 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: encryption algorithm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/18/2013 12:05 AM, Robert J. Hansen wrote: So in other words the message can not be read by some govt genius with a rack of computers?? How would I know? Ask a government genius with a rack of computers. I don't know the extent of the government's capabilities, nor do I want to. That's the kind of knowledge that normally comes with some really strict rules on what you're allowed to say. Oh OK. So there is a chance that someone has a special mathematical trick to reduce the key-space hence their need for things like Saville, BATON, etc. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSsYCZAAoJECrdp7MWSIVbwloH/3/xQFdjbrjc/36x1IdaJm8+ YWy3+g5XwXHZxhZRyFhCMwcMa6p8m4fBNZ3kjFCohCq6NwkvErrMWVtuzrI8JY50 poDmZKhUdxdDXv7Dqj/RnI2dzwa7CmcRO8Cqt1JTY51heeq0E1v1R95uL1QUtGGg v8ekuBwqvzUZLjAUrA3+WR+QZnWwoIzkcd884VEit/H4JZ6JYwyTeEMEhx47hsQE qnN1dZGnv5saJgsaowSDQu/6CvRfmVg8N1DOqJX2fradz1aAJaF4cZ8biO3oXSRY J/pmvtHZ0RA6lZRsWaqyAj18p561waE80w1fYdVChhzKskqzcRanmWO9Nld0wxU= =78sh -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Synchronize UID lists on public and private key -- how?
Am Di 17.12.2013, 10:40:21 schrieb Doug Barton: On 12/17/2013 01:09 AM, Lev Serebryakov wrote: | Is it possible to synchronize UID list without transferring new version | of private key from B to A by external means? No. I can reproduce the problem but it doesn't make any sense to me. Why are UIDs stored in the secring...? But it is possible to sync pubring and secring (i.e. the answer to the OP's question is yes, not no; whether it's fun...): mkdir split-pub split-sec cp public.gpg split-pub cp secret.gpg split-sec cd split-pub gpgsplit public.gpg # looks like this: 01-006.public_key 02-013.user_id 03-002.sig 04-013.user_id 05-002.sig public.gpg cd ../split-sec gpgsplit secret.gpg # looks like this: 01-005.secret_key 02-013.user_id 03-002.sig secret.gpg cp ../split-pub/04-013.user_id ../split-pub/05-002.sig . cat 0* secret.split.gpg gpg --delete-secret-key 0x12345678 gpg --import secret.split.gpg Hauke -- Crypto für alle: http://www.openpgp-schulungen.de/fuer/unterstuetzer/ http://userbase.kde.org/Concepts/OpenPGP_Help_Spread OpenPGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 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: encryption algorithm
On 12/18/2013 2:18 AM, Daniel Kahn Gillmor wrote: Sorry, but NIST does face a crisis of trust, particularly in the area of cryptography, whether either of us wants that to happen or not. Perhaps: but *not over the PRNG they published*. Please stay on point. You are demonstrating a tendency here to stake out a position (NIST is untrustworthy) and argue towards it; and as soon as an argument is refuted, you do a weak backtrack of that argument and stake out a new one in the same direction. Your argument for moving towards RSA-3072 was that you wanted the system to be more even. When pointed out that we could not make the asymmetric component more even with AES-256, you quickly said well, I'm not advocating RSA-15000 and have since pretended you never made that argument. When you made a smear against NIST on the basis of a flawed PRNG algorithm -- and in context of what you were responding to, it's hard for me to believe you were saying anything other than it was a deliberate backdoor introduced with NIST's knowledge -- you backtracked to well, I never said it was witting/willing, and anyway, just putting out a single bad spec is enough to damage trust in them. There's no point in having a discussion about a subject if it starts from a position and seeks arguments to support that position, rather than starting from arguments and hoping it will lead to a position. I firmly believe in the latter. The former is the specialty of bad cable news channels where talking heads scream past each other -- which is the state I fear this discussion has devolved into. I'm going to make one last brief summation of my position. Past that, I am done with this thread. It's not going anywhere useful. 1. 112 bits of keyspace is generally acknowledged to be the minimum level that current applications should support. New crypto code should aim for at least 128 bits; 256 bits is better. 2. The reason for the discrepancy is that when deploying a new system it's far easier to overdesign it. When changing an existing system, one has to deal with a large installed codebase. 3. GnuPG's asymmetric default meets the standard in #1. There is no imminent and pressing need to change. 4. GnuPG's asymmetric default is believed to be secure for about the next 15 years. That meets GnuPG's goal of providing pretty good privacy. 5. When GnuPG introduces ECC support it will be a fine opportunity to deploy new certificates, whereupon the default can be changed to 256 bits of keyspace with minimal disruption to people above and beyond the disruption shifting to ECC will do. 6. No one has presented any reason to shift to 128-bit keyspaces right this very instant, especially when ECC is on the horizon and approaching fast. Since the asymmetric component is expected to be safe for 15 years, we're not in an exposure window. 7. If you seriously believe that a 112-bit keyspace is inadequate, then you need to stop using computers. Pretty much every Authenticode-signed Windows application uses RSA-2048 at maximum. ATMs use 3DES, with a 112-bit keyspace. The HTTPS infrastructure tends to max out at RSA-2048. 112-bit keyspaces are endemic. It would be nice if they'd all move to ECC, and hopefully they will, but we are not facing an imminent Cryptoageddon because society's computing infrastructure uses 112-bit keyspaces. 8. I would like to see GnuPG migrate to 256-bit keyspaces. I'd like to see this migration done in a calm, orderly fashion. Given the total lack of risk presently associated with RSA-2048 -- or for the next 15 years or so -- I'm just fine with waiting a year to make a single cutover to minimize disruption to end-users. You may disagree with these; I imagine you will disagree vigorously. That's fine. But now I trust my position is clear, and we can put this to rest. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
[Announce] [security fix] GnuPG 1.4.16 released
Hello! Along with the publication of an interesting new side channel attack by Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability of a new stable GnuPG release to relieve this bug: Version 1.4.16. This is a *security fix* release and all users of GnuPG versions 1.x are advised to updated to this version. GnuPG versions 2.x are not affected. See below for the impact of the problem. The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility, smartcard support and is compliant with the OpenPGP Internet standard as described by RFC-4880. Note that this version is from the GnuPG-1 series and thus smaller than those from the GnuPG-2 series, easier to build, and also better portable to ancient platforms. In contrast to GnuPG-2 (e.g version 2.0.22) it comes with no support for S/MIME, Secure Shell, or other tools useful for desktop environments. Fortunately you may install both versions alongside on the same system without any conflict. What's New === * Fixed the RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis attack as described by Genkin, Shamir, and Tromer. See http://www.cs.tau.ac.il/~tromer/acoustic/. [CVE-2013-4576] * Put only the major version number by default into armored output. * Do not create a trustdb file if --trust-model=always is used. * Print the keyid for key packets with --list-packets. * Changed modular exponentiation algorithm to recover from a small performance loss due to a change in 1.4.14. Impact of the security problem == CVE-2013-4576 has been assigned to this security bug. The paper describes two attacks. The first attack allows to distinguish keys: An attacker is able to notice which key is currently used for decryption. This is in general not a problem but may be used to reveal the information that a message, encrypted to a commonly not used key, has been received by the targeted machine. We do not have a software solution to mitigate this attack. The second attack is more serious. It is an adaptive chosen ciphertext attack to reveal the private key. A possible scenario is that the attacker places a sensor (for example a standard smartphone) in the vicinity of the targeted machine. That machine is assumed to do unattended RSA decryption of received mails, for example by using a mail client which speeds up browsing by opportunistically decrypting mails expected to be read soon. While listening to the acoustic emanations of the targeted machine, the smartphone will send new encrypted messages to that machine and re-construct the private key bit by bit. A 4096 bit RSA key used on a laptop can be revealed within an hour. GnuPG 1.4.16 avoids this attack by employing RSA blinding during decryption. GnuPG 2.x and current Gpg4win versions make use of Libgcrypt which employs RSA blinding anyway and are thus not vulnerable. For the highly interesting research on acoustic cryptanalysis and the details of the attack see http://www.cs.tau.ac.il/~tromer/acoustic/ . Getting the Software First of all, decide whether you really need GnuPG version 1.4.x - most users are better off with the modern GnuPG 2.0.x version. Then follow the instructions found at http://www.gnupg.org/download/ or read on: GnuPG 1.4.16 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the following files in the *gnupg* directory: gnupg-1.4.16.tar.bz2 (3571k) gnupg-1.4.16.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.4.16.tar.gz (4955k) gnupg-1.4.16.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.4.15-1.4.15.diff.bz2 (26k) A patch file to upgrade a 1.4.15 GnuPG source tree. This patch does not include updates of the language files. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.4.16.exe (1573k) gnupg-w32cli-1.4.16.exe.sig GnuPG compiled for Microsoft Windows and its OpenPGP signature. This is a command line only version; the source files are the same as given above. Note, that this is a minimal installer and unless you are just in need for the gpg binary, you are better off using the full featured installer at http://www.gpg4win.org . Gpg4win uses GnuPG 2.x and is thus not affected by the security bug. Checking the Integrity == In order
Re: Another step towards crowdfunding
On Tue, 17 Dec 2013 20:40, c...@rheloud.net said: How about an RSS-Feed. We used to have one for the News. It is currently disabled but will come back with the new website. 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: [Announce] [security fix] GnuPG 1.4.16 released // workaround
On Wednesday, December 18, 2013 at 9:25 AM, Werner Koch w...@gnupg.org wrote: The paper describes two attacks. The first attack allows to distinguish keys: An attacker is able to notice which key is currently used for decryption. ... While listening to the acoustic emanations of the targeted machine, the smartphone will send new encrypted messages to that machine and re-construct the private key bit by bit. A 4096 bit RSA key used on a laptop can be revealed within an hour. GnuPG 1.4.16 avoids this attack by employing RSA blinding during decryption. = Am not familiar with how RSA 'blinding' works, but am surprised that it cannot be used to 'blind' RSA as to the identity of the key ;-( Here is a potential workaround though: If a sender suspects that the receiver may be in a place where acoustical surveillance can detect the key id, then the sender and receiver can do the following: [1] The sender sends a message encrypted to both the sender's and receiver's usual keys, with an instruction in the plaintext, that if a 'special atypical' key is to be used, then the message is to be sent encrypted to that special atypical key, using the throw-keyid option, as well as encrypting conventionally to a passphrase. [2] The passphrase to be used for conventional encryption is the session key string for the first encrypted message in [1], which the sender and receiver now have, and they can decrypt the messages using conventional encryption. [3] Whenever the correspondents are in an environment 'safe' from this type of acoustic threat, the message can be decrypted using the 'special typical' key. Whatever information is intended to be conveyed by using a 'special key', will still be understood by the receiver. vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
FAQ? Re: please give us safer defaults for gnupg
Am Montag, 16. Dezember 2013 20:42:54 schrieb Werner Koch: May I suggest to read the archives of just a few weeks to collect the reasons why suggestions of using SHA-512 are missing the point. Some folks here must have bleeding fingertips from repeating the arguments over and over. What about placing this as an FAQ in the wiki.gnupg.org? I believe we can then refine the argument, so it can be understood more easily. 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: Another step towards crowdfunding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 18/12/13 00:01, Micah Lee wrote: The problem is you're wanting to make GnuPG go mainstream but then you end up with people seeing this: http://i.imgur.com/53nvUqm.png Yup. That should be avoided. However there are only a few pages that critically need to be https it seems to me. Anywhere that source files are provided clearly needs to be secure. Ideally the manual pages too. But the front page has no need in my opinion. Sam. - -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samt...@jabber.fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKxwAUACgkQ1bR1Itj7YQWX+QEAnWac1Ffn+/t4HyCkjRKGwrfh WyvtTH4A3fLSDvdOmR4A/1aqmhRX2mD/dKQJajbdrR6pvieN+F1CYsYqP1NLZoyz =QKDi -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: FAQ? Re: please give us safer defaults for gnupg
On Wed, 18 Dec 2013 16:09, bernh...@intevation.de said: What about placing this as an FAQ in the wiki.gnupg.org? We have a FAQ which answers a lot of questions around key sizes in “Advanced Topics” section. If something is missing it can easily be added. 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: [Announce] [security fix] GnuPG 1.4.16 released
Werner Koch wrote on 12/18/13, 4:05 PM: Hello! Along with the publication of an interesting new side channel attack by Daniel Genkin, Adi Shamir, and Eran Tromer we announce the availability of a new stable GnuPG release to relieve this bug: Version 1.4.16. This is a *security fix* release and all users of GnuPG versions 1.x are advised to updated to this version. GnuPG versions 2.x are not affected. See below for the impact of the problem. [...] Hi, compiled from source: Version info: gnupg 1.4.16 Configured for: Darwin (x86_64-apple-darwin13.0.0) gpg (GnuPG) 1.4.16 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: ~/.gnupg Supported algorithms: Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Thank you for your work. Charly 0x15E4F2EA Mac OS X 10.9.1 (13B42) MacBook Intel C2Duo 2GHz 13-inch, Aluminum, Late 2008 . (GnuPG/MacGPG2) 2.0.22 - gpg (GnuPG) 1.4.16 TB 24.2.0 Enigmail version 1.6 (20131006-1849) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? You can't conjure up good quality entropy. And if you don't trust symmetric crypto, you can't use that to create an almost-random stream either. 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: gpgsm, certificate expired, different certificate, epa does not encrypt
On Mi, Dez 18 2013, Uwe Brauer wrote: I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. I have several email accounts with different (comodo certificates). Now one certificate for the address addre...@gmail.com has expired. However I want to send an email from address2 (whose certificate is *not* expired) to a recipient. However when I try to encrypt this message, it does not work. Hi Uwe, if I understand you correctly, you fail to encrypt to your From address, right? If I’m not mistaken, epa does not encrypt to From addresses by default. What did you do to make that happen? Does your gpgsm.conf contain “encrypt-to” for the expired certificate? Best wishes Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
gpg-rsa-key decryption with a mobile
Here, we describe a new acoustic cryptanalysis key extraction attack, applicable to GnuPG's current implementation of RSA. The attack can extract full 4096-bit RSA decryption keys from laptop computers (of various models), within an hour, using the sound generated by the computer during the decryption of some chosen ciphertexts. http://tau.ac.il/~tromer/acoustic/ http://tau.ac.il/%7Etromer/acoustic/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Another step towards crowdfunding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/18/2013 07:32 AM, Sam Tuke wrote: | On 18/12/13 00:01, Micah Lee wrote: | The problem is you're wanting to make GnuPG go mainstream but then you end | up with people seeing this: http://i.imgur.com/53nvUqm.png | | Yup. That should be avoided. However there are only a few pages that | critically need to be https it seems to me. Anywhere that source files are | provided clearly needs to be secure. Ideally the manual pages too. But the | front page has no need in my opinion. Well, completely aside from the fact that encrypt everything you can is a good default policy, providing a consistent user experience is a good reason to make https the only access method. At very least, making sure that if a user enters the site via https that they stay on https (protocol-agnostic links/URLs). A better question would be why would you not want to serve all the pages via https? Please don't say higher CPU usage because the difference is negligible on any modern system. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQEcBAEBCAAGBQJSseJiAAoJEFzGhvEaGryET34H/1CP9ZXka+/6Jh4RRu+bWHQy ye1aUJmqqsBG/hYlRi3Bz3UhmyLiQUtIE9CyiXx3cU88Cmb+u2MsoiLwasFxxRtU FIik1zi4iudnkpZOzKKzlHSe1rb8qvOCB4RUYX/E9F990mU5dCL02bKhHMbqIhjb +xkYGnje3bSv/kvEmPVb862tQD2k9fLswlAmdDtXClMbG6ZQyZv3olfZ87RpN2EC VZGx4FVIyVjnAlGmTs2/U5U6oMdzZp5ScAu4z2S2FwnGc98ZNn1JAzGNh8BlKVix lw/3Fhzovjhjbxvy/PxNN3prmgf2IOPvqkl3gvdt2xHkEg9KqBsaiL8/HBs7yz0= =m2a9 -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpg-rsa-key decryption with a mobile
On Wed, 18 Dec 2013 18:31, sys...@ioioioio.eu said: Here, we describe a new acoustic cryptanalysis key extraction attack, applicable to GnuPG's current implementation of RSA. The attack can Well that is what I posted a few hours ago to this list ;-). 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
GPG Blog: Getting Goteo approval
Getting Goteo approval == Posted 18th December 2013 by Sam Tuke http://blog.gnupg.org/20131218-getting-goteo-approval.html The targets are set, the rewards are prepared, the press release has been edited and translated, and now we’re waiting for approval from the crowdfunding platform Goteo. Goteo is like indiegogo, but more forward thinking. It has a special focus on communal benefits and rewards - projects that benefit society as a whole, not just project donors (though they can get special rewards too). Every ’good’ produced by a campaign on Goteo, be it artwork, software, event, or manufactured product, has a license assigned to it, like GPL or Creative Commons, and as well as asking for money, projects ask for other forms of help called “non-economic needs”, like translations or product testing. Goteo’s own source code is Free Software too, meaning anyone can run their own Goteo crowdfunding server. That’s the feature that swung our decision to use it for GnuPG. Because the type of project on Goteo is quite specific however, the acceptance phase of launching crowdfunding is taking us longer than expected. Right now we’re working with Goteo’s small team to answer questions which aren’t on the webforms you fill out when you design your project with their system. I’m hoping to provide what’s necessary and get acceptance quickly. As soon as we have it the crowdfunding will launch and newsletter subscribers and Twitter followers will be the first to know. -- Sam Tuke Campaign Manager Gnu Privacy Guard Tel: +49 176 81923811 IM: samt...@jabber.fsfe.org signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 12/18/2013 08:53 AM, Peter Lebbing wrote: On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... I understand that you're not interested in an argument that the encryption of the entire secret may not be secure, but everything is secure right up until it isn't. (Robert, please ignore my tortuous use of secure in that sentence.) :) The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. Completely aside from the possibility (however remote) of the crypto failing, I'm also thinking of layer 9 issues that can come into play. For example I was the one who proposed using SSS to distribute portions of the root DNSSEC KSK to members of the community to provide a disaster recovery procedure should something catastrophic happen to ICANN. They didn't finish the root key protocol until after I left IANA, and what they ended up doing instead was using a HSM to store the key. But they did end up using SSS with members of the community to share the password for the HSM, for the same reason I proposed. If the HSM hadn't come into play the politically expedient thing to do would have been to distribute pieces of the secret, rather than pieces of the key used to encrypt the secret. Now I realize that most of the people on the list aren't interested in layer 9, but some of us live in a world where it is necessary to do so. :) although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? I don't, I was suggesting that your concerns are valid and that the author of the new software is responsible for addressing them. Doug ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
On 12/18/2013 1:25 PM, Doug Barton wrote: (Robert, please ignore my tortuous use of secure in that sentence.) :) Hey, I was being *nice*. I wasn't even pointing out that 3DES only has 112 bits of keyspace... ;) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: encryption algorithm
On Dec 18, 2013, at 5:41 AM, Werner Koch w...@gnupg.org wrote: On Wed, 18 Dec 2013 02:27, r...@sixdemonbag.org said: because you just shifted to arguing that since GnuPG defaults to AES-256, we need to use RSA-15000 by default otherwise the asymmetric FWIW: The rationale why we use the order AES256,192,128 is for compatibility reasons with PGP. If gpg would define AES128 first, we would get the somewhat confusing situation: gpg -r pgpkey -r gpgkey ---gives-- AES256 gpg -r gpgkey -r pgpkey ---gives-- AES PGP prefers AES256 for the simple reason that the marketing deptartment told the engineering that 256 sounds stronger than 128 (according to one of their lead developers). Plus the related reason why Camellia is ordered the same way: because it would look strange to have AES 256,192,128 and then Camellia 128,192,256 ! Now that we have the preference list scoring, though, the above change is no longer necessary. Instead of using the command line ordering, the score code handles it the same way regardless. In the above example, AES (not AES256) would be chosen no matter what the order. The rationale from back then was: /* Note the '' here. This means in case of a tie, we will favor the lower algorithm number. We have a choice between the lower number (probably an older algorithm with more time in use), or the higher number (probably a newer algorithm with less time in use). Older is probably safer here, even though the newer algorithms tend to be stronger. */ I don't think it's worth changing the default ranking back at this point though. David ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm, certificate expired, different certificate, epa does not encrypt
Jens == Jens Lechtenboerger clou...@informationelle-selbstbestimmung-im-internet.de writes: On Mi, Dez 18 2013, Uwe Brauer wrote: I am using Xemacs, gnus the epa pkg for encrypting s/mime using gpgsm. Hi Uwe, if I understand you correctly, you fail to encrypt to your From address, right? Not really, my from address is o...@mat.ucm.es the corresponding certificate is *NOT* expired. I have also a gmail account whose certificate is expired, but which does not play any role here. Or should not play any role here. If I’m not mistaken, epa does not encrypt to From addresses by default. What did you do to make that happen? Does your gpgsm.conf contain “encrypt-to” for the expired certificate? No! Yuk there is indeed a line! :'( encrypt-to burr...@gmail.com Why the hell is this line there? Maybe I did some testing and forgot about it. :-D Thanks very much Uwe smime.p7s Description: S/MIME cryptographic signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Sharing/Storing a private key
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Well, I'm really sorry to have set up such a conversation :o) As I said earlier I'm not quite good at crypto-things, all I wanted to do was to protect my private key easily in case of HDD error. And all I wanted to do with this little tool was to share it with you. If you can explain to such a nooby-noob like me what matters, I'll try to do my best not to make you loose your time ;o) Mindiell, Le 18/12/2013 17:53, Peter Lebbing a écrit : On 16/12/13 23:41, Doug Barton wrote: but one argument against what you're suggesting is that it's only as secure as the encryption used in step 1 of the hybrid approach. If only everything in cryptoland was only as secure as 3DES... The ability to apply SSS to the entire secret would be quite valuable I don't see why. If this is because you avoid insecurities in symmetric crypto, I just don't buy it. Otherwise, please explain. although your concern about entropy use is something that should be addressed explicitly. And how do you propose to do that? You can't conjure up good quality entropy. And if you don't trust symmetric crypto, you can't use that to create an almost-random stream either. Peter. - -- Mindiell -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlKyCscACgkQUrT9WwBwY7zakQD/YTei8nEPmIL+aiPrF+lVqJPP POvkULr4DoDGA+bV63cA/2rUxaY8epxpdtbQtT44zEJ6fL6cwO3Go4jtRPy2LSNu =i3nj -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
How much load are keyservers willing to handle?
Hi, I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. Cheers, adrelanos [1] http://lists.debian.org/debian-security/2013/12/msg00031.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
On Wed, Dec 18, 2013 at 10:20:26PM +, adrelanos wrote: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. [1] http://lists.debian.org/debian-security/2013/12/msg00031.html 1) setup your own DNS so you can shut things off if anything goes wrong! (you can use dyn.com or others, no servers required) 2) probably best discussed on the sks-devel list, Reply-To set accordingly 3) try running your own keyserver(s), SKS is easy enough to deploy -- Jason Harris | PGP: This _is_ PGP-signed, isn't it? jhar...@widomaker.com _|_ Got photons? (TM), (C) 2004 pgpya6iSgyHv5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The question I have is, What problem are you trying to solve? I am certain that Debian Security already has a protocol in place for how to handle compromised certificates. Is this protocol flawed or lacking? What problem does it not address which this idea will solve? The next question is, Why is it important the certificate be retrieved from the keyserver network? When talking about the global apt repositories, it's likely they have access to multiple of orders of magnitude more bandwidth than the keyserver network. Why not host the signing key on the apt repo server? Could keyservers cope up with the load? Good question. Probably, but some keyserver operators might view it as rude. Best to ask on sks-de...@nongnu.org. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Robert J. Hansen: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The question I have is, What problem are you trying to solve? What in case the apt signing key gets compromised. What is the mechanism of invalidating the client's keys so they can't fetch malicious files from any mirrors. I am certain that Debian Security already has a protocol in place for how to handle compromised certificates. Certainty is what sometimes makes the world an unsafe place. I would have supposed that this is the case as well, but after verifying such suppositions I was often quite surprised. Is this protocol flawed or lacking? It is non-existent. See my original question [1] and also in my current discussion [2] someone would have stepped in and said we already have this. Since this didn't happen and since I also looked through apt's sources, I am certain this thing doesn't exist. Can't prove it though, Russell's teapot you know. ;) What problem does it not address which this idea will solve? When there is reason to believe, the apt signing key has been compromised, the revocation certificate can be spread through a channel other than apt updates (which are compromised). The next question is, Why is it important the certificate be retrieved from the keyserver network? It's not important. I didn't mean to say that. It's just simpler to code (for me, in the draft in my head). And if they don't mind, I'll go the easy way, if they mind, I'll come up with another solution. When talking about the global apt repositories, it's likely they have access to multiple of orders of magnitude more bandwidth than the keyserver network. Yes. Why not host the signing key on the apt repo server? They could of course re-use their existing mirror network for this. Could keyservers cope up with the load? Good question. Probably, but some keyserver operators might view it as rude. Best to ask on sks-de...@nongnu.org. Will do. [1] http://lists.debian.org/debian-security/2013/10/msg00065.html [2] http://lists.debian.org/debian-security/2013/12/msg00031.html -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJSsmssXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7v26MP/R1TMYHHE6l0Ayhs6qZS3iGf fKDKM8qVfJUo/YBxAaYXVtfD6Ovs4jgKR7KXvy/xzsq4XdoDWMEgsZG3MLP+JiyS j3g7BEVns+55A/vPDysMUstrwQPhSBklnA+my3QG4UnDdKUjx8/m3jxWbMphe+sj fdMtOAquRCj72dIgtiYSYCfOnb9UN7EaEWrIyK57c9J5ygD6HTOjU4VoNKwLfHnf W8IAeTv4N1PDZIZ/dPteDkBYuCdgJgB+QAYh7yJ5AuCV1dhiTkip92PkE3+tCVHs /mufO9Ffy3mAtsD7U0H6Mq2rCqa8v3tHpraMROHdyuyAK1VJqbfveOkeKHjL2ocZ 2uJbAF/m/JmQFLPH/+V8siItg2qhYS2I6qhxE5RvS1FmbwPf/yvulSQQmaNJNPLE pxR7LbOAS9zUfJsy44r+t4n6N64qDmEBk6g+tRLMpn0MC8zfdSvZBxxWP9JVkWc1 C8JHeluKH8jrQbbLSBeG9Ie8WUMSmJpqfQLI6jK6sW2zXRA11VSSFNyPB48vsuZB 9kUtJ7ido0/npI/225JN/oQJ3RaTKj62OyDQSW8X4C4gMWFj8EZAvoSj/nKiKUtB RH1IJ8GBCsK1QR5Biia/KchYlAW+HKpJpOrn6C8Wm+ubBooYuK7csud5exWZLS+Q VAq22Rq6RdgitL1O/4OJ =O6my -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How much load are keyservers willing to handle?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Jason Harris: On Wed, Dec 18, 2013 at 10:20:26PM +, adrelanos wrote: I am planing to write a script, which will refresh the apt signing key before updating using apt-get update. The script might get accepted in Debian. [1] With my Whonix hat on, it's safe to say, that this script will be added to Whonix (which is a derivative of Debian). Writing that script would be much simpler if it could re-use the existing keyserver infrastructure. Now imagine if this gets added to Debian, that all users of Debian and all its derivatives will always refresh their signing key against keyservers? Could keyservers cope up with the load? The legal question would be interesting, but don't worry, if you ask me not to use keyservers for this, I'll use a mechanism outside of keyservers. [1] http://lists.debian.org/debian-security/2013/12/msg00031.html 1) setup your own DNS so you can shut things off if anything goes wrong! (you can use dyn.com or others, no servers required) Interesting idea. I guess in that case I'll got with what I wrote under 3). 2) probably best discussed on the sks-devel list, Reply-To set accordingly Okay, I'll repost there. 3) try running your own keyserver(s), SKS is easy enough to deploy I don't have a lot servers with bandwidth available. And rather than spending money on that, in case keyservers decline, I am probably re-using sourceforge.net's infrastructure. I already asked them once about a similar thing [they're willing to host our project news files (comparable small files with comparable load)], they'll most likely accept that as well. I don't know how they or some others manage it, but their traffic comes virtually for free. -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJSsmskXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5QjE1NzE1MzkyNUMzMDNBNDIyNTNBRkI5 QzEzMUFEMzcxM0FBRUVGAAoJEJwTGtNxOq7vRloP/i0vZRFCyQY7NBc1ZxPuVJpA PPiKuXODo/+jG/VX8krkYWaAIL9otCwrUMFlS0LxFYHvtfx03NaISaGG1WV3mWJA 1KiqODX+5RszCf/By4tW9JE1EdNeOjZM+XhPZ6oRMQogpmtVAe1EFIscQ84H3k0T SOcd4I//Q+7qkomhEu+C0crSogzzyvYRhG52a7IGDUCLRrhAc+CX0WbYqc5OZj5c qHGdDMPbhpa0/Z514pYuewUu4tQDc3NLZ1fpZGd6GeY3zC/grrLEtnbQogkjeiwB nIu90TC5yYGw8B9reJlfb6lq6s+QG/bs6yweHVg4oaa/i7Lfe9O6/WMshshuu62z sMt3eyAeXTyKFYPv9kugSFNkqGHWlDome3PJzYOqRE3BkxYU21qegzTfNUD50jpH pNVX5I7wSecpvNa3yIEE9000FDOdwvx/sJrEhmlY90J12BHZATJHQgcgq04GAPQT OL+kYRhifdS6BE7VXT2eHepQzviGScPZ09n+5ZpkX6nn/pcW84McUYg3qpam8OoU hGmcoJ0V5dnGNJjmzdMfeej1TsYKjE+uWpAod/lPnXHry/4FYTTSxrdfyfaRQOJx yd2DkcjZ0EzP/13DS8GxgH53FKiqxIQxjDhVyBNeSVnjB/f6TbuMJH3ZEl0FL3gn /ex0cwPRQ6lVxLtcpg8f =/K1w -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
