Re: Seperate RSA subkeys for decryption and signing or one for both?
On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: Hello, are there arguments for preferring either a) having one RSA subkey for decryption only and one for signing only or b) having only one RSA subkey for both decryption and signing? Do any problems arise with the smartcard if the same key shall do different tasks? Keys can become used up so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
Am Di 04.12.2012, 13:19:11 schrieb Hubert Kario: Keys can become used up so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. I remembered having read something like that. But does this refer to signing only? Are decryption keys not affected by that? The advantage of separate subkeys would be then that the non-used up key could keep active longer. That may be an argument against signing emails by default ;-) or at least for longer signature keys. Hauke -- ☺ PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04) 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: Is it safe to rename file.gpg to `md5sum file`?
There isn't enough entropy in a filename for an MD5 checksum to give much in the way of secrecy. It seems that MD5 checksum is computed from file contents, not name. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
On Tuesday 04 of December 2012 14:14:34 Hauke Laging wrote: Am Di 04.12.2012, 13:19:11 schrieb Hubert Kario: Keys can become used up so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. I remembered having read something like that. But does this refer to signing only? Are decryption keys not affected by that? The advantage of separate subkeys would be then that the non-used up key could keep active longer. That may be an argument against signing emails by default ;-) or at least for longer signature keys. Leaking is caused by signing, if your using the same key for signing and encryption, then you can use the signatures to speed up the attack on encryption. If you're encrypting with one key and signing with other then the encryption key doesn't need to be changed, as the encryption is done with public part anyway -- you don't leak any information that's not already avaiable to the attacker. Signature keys should be changed regularly, every few hundred thousand signatures or so. In typical business deployments you don't have users that send over three hundred signed e-mails a day, every day (including holidays), and the certificates are valid only for a year. So you don't go over the few hundred thousand signatures limit. It is something you should keep in mind when you're using GPG and send lot of e-mails, though -- it is easy to use the same key for many years... Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
RFC 4880 says this in the Security Considerations part: * Many security protocol designers think that it is a bad idea to use a single key for both privacy (encryption) and integrity (signatures). In fact, this was one of the motivating forces behind the V4 key format with separate signature and encryption keys. If you as an implementer promote dual-use keys, you should at least be aware of this controversy. Where's your question coming from? As a theoretical musing, it's interesting. In practice, I don't see why you would ever create a subkey with both capabilities set.[1] Also note that it is useful to keep around (and backup) an encryption subkey, to decrypt old stuff. A primary key is useful to backup as it collects certifications. But a signing subkey is not useful to keep around. You might want to refresh your signing subkey more often than your encryption key for that reason. Peter. [1] That doesn't mean there is no reason. -- 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: Seperate RSA subkeys for decryption and signing or one for both?
On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: Hello, are there arguments for preferring either a) having one RSA subkey for decryption only and one for signing only or b) having only one RSA subkey for both decryption and signing? Do any problems arise with the smartcard if the same key shall do different tasks? Keys can become used up so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. Do you have a reference for this? I thought the major reason to use separate signing/encryption keys was that if a user could be persuaded to sign a chosen encrypted text with the same key, the decryption key would be revealed. http://security.stackexchange.com/questions/1806/why-should-one-not-use-the-same-asymmetric-key-for-encryption-as-they-do-for-sig I've never read before that a key could be used up in this way. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: Hello, are there arguments for preferring either a) having one RSA subkey for decryption only and one for signing only or b) having only one RSA subkey for both decryption and signing? Do any problems arise with the smartcard if the same key shall do different tasks? Keys can become used up so it entirely depends on how often you use it. What I mean by that, is that any signing operation leaks some information about the key used for signing (generally far less than few tens of a bit). If you have signed tens of thousands of documents with it, an attacker can recover substantial portion of the key and speed up the key recovery. Do you have a reference for this? I don't have one at hand and can't find one through quick googling. I'm not sure where I've got this info from, it may have been in Applied Cryptography. Basically anything I have to back this is the general recommendation for TSA used in SignServer: http://www.signserver.org/manual/complete.en.html#Limiting%20the%20number%20of%20signatures but unfortunately they don't provide any rationale for this either. Logically though, if you have a known function that takes two parameters, A and B. You know B, function's output and size of A, then provided enough pairs of B and output you theoretically can say something about A (as A is constant). Of course, this works only because RSA is reversible and you know A' -- the public part of key. The problem is defining enough pairs, probably the 10 I mentioned is quite conservative. On one hand, such a limit is hardly a problem for anybody but automatic systems (which can be easily configured to rotate keys), on the other hand, this attack was described as purely theoretical AFAICR. I thought the major reason to use separate signing/encryption keys was that if a user could be persuaded to sign a chosen encrypted text with the same key, the decryption key would be revealed. How do you propose an attacker could force me to sign data I already encrypted? In both cases (encryption, signature) I don't process the data itself but either its hash or random data used as key for symmetric cipher. I may be wrong here, but I'm quite sure such situation is simply impossible to happen with GPG or other standard protocols (S/MIME, PKCS) http://security.stackexchange.com/questions/1806/why-should-one-not-use-the- same-asymmetric-key-for-encryption-as-they-do-for-sig See CodesInChaos comment Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate RSA subkeys for decryption and signing or one for both?
On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: Do any problems arise with the smartcard if the same key shall do different tasks? Keys can become used up so it entirely depends on how often you use it. Do you have a reference for this? Sorry for double posting, here's some reference: http://security.stackexchange.com/a/18242/3306 Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 30/85 tel. +48 (22) 646-61-51, 646-74-24 www.qbs.com.pl ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Seperate RSA subkeys for decryption and signing or one for both?
On Tue, Dec 4, 2012 at 5:32 PM, Hubert Kario h...@qbs.com.pl wrote: On Tuesday 04 of December 2012 16:07:26 Nicholas Cole wrote: On Tue, Dec 4, 2012 at 12:19 PM, Hubert Kario h...@qbs.com.pl wrote: On Monday 03 of December 2012 12:41:10 Hauke Laging wrote: Do any problems arise with the smartcard if the same key shall do different tasks? Keys can become used up so it entirely depends on how often you use it. Do you have a reference for this? Sorry for double posting, here's some reference: http://security.stackexchange.com/a/18242/3306 Ah. That's an attack on the Hash function, not the key. And even then, it seems far too difficult to be realistic, assuming that I read it correctly and assuming it is correct! N ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Fwd: Seperate RSA subkeys for decryption and signing or one for both?
Meant to post this to the list. Blame gmail. -- Forwarded message -- From: Nicholas Cole nicholas.c...@gmail.com Date: Tue, Dec 4, 2012 at 7:10 PM Subject: Re: Seperate RSA subkeys for decryption and signing or one for both? To: Hubert Kario h...@qbs.com.pl How do you propose an attacker could force me to sign data I already encrypted? I think the attack merely specifies a chosen text - but at any rate, the point is that there might be a system (eg. a badly designed time-stamping service) that might naively sign data supplied by an attacker, and in those cases having a signing and encryption key that are the same would be a Bad Idea. Note, though, that PGP 2.6.3 did use the same key for both; the attack is a (mostly) theoretical one. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is it safe to rename file.gpg to `md5sum file`?
On Tue, 4 Dec 2012 14:40:22 +0200, yyy y...@yyy.id.lv wrote: There isn't enough entropy in a filename for an MD5 checksum to give much in the way of secrecy. It seems that MD5 checksum is computed from file contents, not name. Yes, I meant to use the MD5 checksum of the original file, not its original name. I'm still interested whether this would be insecure? I found a discussion on this list in 2011, where user atom wrote: just make sure you're hashing the file-NAME, not it's contents. of course, if you don't lose your db, then there's nothing wrong with hashing the contents, or even a counter or random string. hashing the file-NAME is just an idea that makes recovery of the db possible if you know the format and range of the file-names (and any secret that may be used). the real trick is to just do something secure and consistent... sha1 does the job. (http://www.mail-archive.com/gnupg-users@gnupg.org/msg15110.html) He states it's not a problem to hash the files contents, but it seems to be thought of no different than counter and random string - this are completely different things IMHO. And, by the way, how could the hash of a filename be used to reconstruct the filename (as atom says ... makes recovery of the db possible ...) There is no such thing as inverse-md5sum, is there? You'd still need brute force to find the original name? Thanks Ben ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Keypad support for PC/SC card readers?
Hello I trid it with gnupg 2.0.19-1 from debian testing - PIN is not requested from the card reader. here is the log file. I did use testing keys and non-productive PIN so I hope I did not post anything sensitive 2012-12-04 22:05:10 scdaemon[16008] listening on socket `/tmp/gpg-iJ5FQq/S.scdaemon' 2012-12-04 22:05:10 scdaemon[16008] handler for fd -1 started 2012-12-04 22:05:11 scdaemon[16008] reader slot 0: not connected 2012-12-04 22:05:11 scdaemon[16008] slot 0: ATR=3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=A4 p1=00 p2=0C lc=2 le=-1 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 A4 00 0C 02 3F 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=6B00 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=A4 p1=04 p2=00 lc=6 le=-1 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 A4 04 00 06 D2 76 00 01 24 01 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=4F lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 4F 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=16 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:11 scdaemon[16008] AID: D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=5F p2=52 lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 5F 52 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=10 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:11 scdaemon[16008] Historical Bytes: 00 31 C5 73 C0 01 40 05 90 00 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=C4 lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 C4 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=7 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 00 20 20 20 03 00 03 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A D6 EA 4C 60 4A 5B A6 50 C2 82 52 95 30 82 0A E5 BB 3D 0A 33 95 C6 3C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 CD 0C 50 BE 63 F2 50 BE 63 F2 50 BE 63 F2 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=5E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 5E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=0 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 2012-12-04 22:05:11 scdaemon[16008] Version-2 ..: yes 2012-12-04 22:05:11 scdaemon[16008] Get-Challenge ..: yes (2048 bytes max) 2012-12-04 22:05:11 scdaemon[16008] Key-Import .: yes 2012-12-04 22:05:11 scdaemon[16008] Change-Force-PW1: yes 2012-12-04 22:05:11 scdaemon[16008] Private-DOs : yes 2012-12-04 22:05:11 scdaemon[16008] Algo-Attr-Change: yes 2012-12-04 22:05:11 scdaemon[16008] SM-Support .: no 2012-12-04 22:05:11 scdaemon[16008] Max-Cert3-Len ..: 2048 2012-12-04 22:05:11 scdaemon[16008] Max-Cmd-Data ...: 2048 2012-12-04 22:05:11 scdaemon[16008] Max-Rsp-Data ...: 2048 2012-12-04 22:05:11 scdaemon[16008] Cmd-Chaining ...: no 2012-12-04 22:05:11 scdaemon[16008] Ext-Lc-Le ..: yes 2012-12-04 22:05:11 scdaemon[16008] Status Indicator: 05 2012-12-04 22:05:11 scdaemon[16008] GnuPG-No-Sync ..: no 2012-12-04 22:05:11 scdaemon[16008] GnuPG-Def-PW2 ..: no 2012-12-04 22:05:11 scdaemon[16008] DBG: send apdu: c=00 i=CA p1=00 p2=6E lc=-1 le=256 em=0 2012-12-04 22:05:11 scdaemon[16008] DBG: PCSC_data: 00 CA 00 6E 00 2012-12-04 22:05:11 scdaemon[16008] DBG: response: sw=9000 datalen=217 2012-12-04 22:05:11 scdaemon[16008] DBG: dump: 4F 10 D2 76 00 01 24 01 02 00 00 05 00 00 12 98 00 00 5F 52 0A 00 31 C5 73 C0 01 40 05 90 00 73 81 B7 C0 0A 7C 00 08 00 08 00 08 00 08 00 C1 06 01 08 00 00 20 00 C2 06 01 08 00 00 20 00 C3 06 01 08 00 00 20 00 C4 07 00 20 20 20 03 00 03 C5 3C BA F7 CF 1F 37 93 D7 CA 56 25 35 E9 45 3C F3 78 19 5B B1 40 06 90 84 2F E5 88 92 F0 B9 BC F7 61 D2 33 94 64 B6 0B 2A
Seperate Master Key and signing/encrypting subkeys method
GnuPG-Users: I was wondering where that article was about seperating the master key from daily subkeys (both signing and encrypting). I can't seem to find it. Are there other articles on the similar methodologies that are still secure. And is it still recommended that I sign another's keys with the master signing key? Thanks in advance. Allen Schultz attachment: allen_schultz.vcf___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Seperate Master Key and signing/encrypting subkeys method
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 El 04-12-2012 18:18, Allen Schultz escribió: GnuPG-Users: I was wondering where that article was about seperating the master key from daily subkeys (both signing and encrypting). I can't seem to find it. Are there other articles on the similar methodologies that are still I can't find it now, but found this: http://www.mentby.com/Group/gnupg-users/offline-primary-key.html It lacks the screen captures, but has the juicy information required to do it. secure. And is it still recommended that I sign another's keys with the master signing key? The master key is the only key that can sign other keys, and yes, your sub-keys must be signed by your master key (it is done automatically), if not, somebody can add rogue keys. Best Regards -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (MingW32) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBCAAGBQJQvo3CAAoJEMV4f6PvczxA/MIH/AhYMkfT07fCqu6denLuSwQ6 O0+TE6KDFqOQazTiBB3B5Iy8w5xAnuUaqeRiP9uce+q2Kf12at2aOUNjvzDXBRTK DYDy48WBLXIs3E+FEAbagBUbqqNdJiGQV7EpbICVUxcGJRxHmCKs03tYB0yRS1O3 LNehI02WGKi5wS4TSyq6bmp3nvGJEjLXKnwqCDNi++YCW5yUyNtvvx0mD9BQSZg9 oaUq5wxM9Gk1gzzFlomR80y1GBgsop4dM4jqqv1PdrfM/b4BD3CMeqZRWa22BUUj IxNFKcswYnmxZyDYiOrpQT/Yl3A2DRBJSBOE4G4OMAOdRzf80ey/AQyOn4CVV50= =InEO -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Is it safe to rename file.gpg to `md5sum file`?
On 12/4/2012 3:03 PM, sben1783 wrote: Yes, I meant to use the MD5 checksum of the original file, not its original name. I'm still interested whether this would be insecure? Let's not even use the word insecure, since that word is wholly subjective: there's no agreed-upon definition for what it means. Instead, let me ask a different question: what, precisely, are you trying to accomplish? And, by the way, how could the hash of a filename be used to reconstruct the filename (as atom says ... makes recovery of the db possible ...) There is no such thing as inverse-md5sum, is there? You'd still need brute force to find the original name? Sure, of course there's inverse-md5sum -- after a fashion. Many files bear names that are just a couple of short words: Tuesday report.doc, for instance. So you go through a dictionary and compile a list of every one and two--word filename, separating by underscores and spaces, and using the top 100 file extensions. There are about 5,000 words in common usage in English. (A native speaker will have a larger vocabulary, but you can get by quite well on 5,000 words.) Every possible one and two-word combo from this list would amount to about 25 million entries in the database: multiply by, say, four, to represent different conventions for capitalization and spacing and whatnot, brings you to 100 million. Multiply by the top 100 file extensions and you get 10 billion. Each of those records would require about 100 bytes of storage, or 1 trillion bytes. You could easily store it on a $100 hard drive. This is what's called a dictionary attack. There are other much better ways to attack it: rainbow tables, for instance. But this is enough to show you that MD5 is nowhere near as hard to reverse as you might think. If you're creating filenames based on the MD5 hash of the entire file, that would be (probably) nontrivial to reverse: if you're creating filenames based on the MD5 hash of the original filename, you're playing with fire. That said: please don't use MD5. Please use a better, stronger hash algorithm like SHA-256, SHA-512 or SHA-3 instead. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
