gpgsm signatures fail starting with 2.1.0-beta864
Hi there, I cannot sign messages with gpgsm any more. beta834 was (and is) still working, with beta864 and beta895 invalid signatures are created: --8---cut here---start-8--- echo Hi test.txt gnupg-2.1.0-beta864/sm/gpgsm -o test.txt.sig --sign test.txt gpgsm --verify test.txt.sig --8---cut here---end---8--- gpgsm: invalid signature: Falsche Unterschrift Note that I’ve got multiple keys, the first one is expired, one is revoked, and one is valid. Thus, I need to use --local-user to create signatures (otherwise, the expired key is tried). Also, I don’t know whether this makes a difference: My current key is stored on a USB token, while the other ones are not. Finally, if I sign with the expired key (with --faked-system-time), then a valid signature is created. With --debug-level guru, I don’t see noteworthy differences in the failing and succeeding cases. Thanks Jens ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: gpgsm signatures fail starting with 2.1.0-beta864
On Wed, 29 Oct 2014 09:00, lech...@wi.uni-muenster.de said: Note that I’ve got multiple keys, the first one is expired, one is revoked, and one is valid. Thus, I need to use --local-user to create signatures (otherwise, the expired key is tried). I can't replicate that while also using --local-user. The only changes for gpgsm since beta834 are related to the key storage. Without any log output I can't help very much. Please check that the correct gpg-agent is used and not some older version - has it been started and is still running after the test (gpg-connect-agent 'getinfo version' /bye) Also, I don’t know whether this makes a difference: My current key is stored on a USB token, while the other ones are not. For verification the card is not used. Are you sure that the signature has been created properly? I heard of problems with pcscd and policy-kit. Maybe you missed an error message. 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: key length/size RSA discussion/recommendations in the wiki
Because this gets asked quite often, I've started to capture some arguments of the debate how long RSAs could/should/can be at http://wiki.gnupg.org/LargeKeys puts on his FAQ maintainer hat I thought we largely addressed this in the FAQ, sections 11.1, 11.2, 11.3, 11.4 and 11.5. Do we need to address it in more depth? If so I'm happy to write an extension to the FAQ. takes off his FAQ maintainer hat signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) 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: key length/size RSA discussion/recommendations in the wiki
Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) Sure you can. To brute-force a 128-bit RSA key would require you to check every prime number between two and 10**19. There are in the neighborhood of ten quadrillion of them. You could break a 128-bit RSA key for under $100 of computation on an Amazon cloud instance. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 10/29/2014 at 3:22 PM, Robert J. Hansen r...@sixdemonbag.org wrote: Why is brute force even mentioned in something about RSA? You couldn't brute-force a 128 bit RSA key. I'd say 2048 bit quite covers it 8-) - Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... vedaal ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 2014-10-29 21:49, ved...@nym.hush.com wrote: Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... No, I'm using a strict definition of brute force. For p = 2^63 to 2^64-1 For q = 2^63 to 2^64-1 If p * q == n: Break Next Next You're free to adapt the order of tries of p and q, though. Happy breaking! I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Peter. PS: I'm assuming a 128-bit RSA key is made up of two 64-bit primes. -- 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: key length/size RSA discussion/recommendations in the wiki
More likely 128 was a typo for the more common older RSA key of 1028 ... Either-or. RSA-1024's dangerously close to being brute-forceable, too. We've already brute-forced RSA-768 and we're closing in on RSA-890. I haven't looked into how well the general number field sieve parallelizes, but I wouldn't want to take bets on how long RSA-1024 could stand up to a massive Amazon Cloud instance. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
No, I'm using a strict definition of brute force. Technically, brute force is testing every *possible* value... not values that you know aren't going to work. Why test those? If you're trying to factorize 2701, for instance, you can feel free to skip dividing by 2 (doesn't end in an even number), 3 (sum of the digits isn't divisible modulo three), 4 (already know it's not divisible by 2), 5 (doesn't end in a 5 or a 0), 6 (not divisible by 3 or by 2), etc. If your brute-forcer is testing values that cannot possibly be correct, then you're using an inefficient brute-forcer. Get a better one. :) I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Depends. I think so. But if you're taking an exam sometime in the near future, I think you should answer this however your professor wants. :) ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On 2014-10-29 22:30, Robert J. Hansen wrote: Technically, brute force is testing every *possible* value... not values that you know aren't going to work. Why test those? Well, why not restrict ourselves to primes whose product equal the modulus? I could solve any key in constant time that way. The distinction obviously(?) is in the cost of computing what makes a possible. But that's the thing about brute force that I thought was not included: using computation to speed up your process, and using insight into the mathematical properties of an algorithm. But you are obviously more in touch with the material than me. If you refer to just testing primes as brute force, I don't think it should be so easily dismissed as I initially did. 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
changing the user PIN for a smartcard in a script
I'm programming the smartcards on a bunch of YubiKey NEO tokens. Before I give the token to the user, I would like to allow them to pick a new user PIN and set it. I don't need to know their PIN and I actually don't *want* to know it. Ideally, I would run a script, have the user type in the new PIN, and the script would run gpg --change-pin, do another thing with the PIN string after that, then discard it. The problem, of course, is that pinentry is launched. Now the user has to type the PIN several times. It's cumbersome and error-prone. I've learned how to disable the pinentry GUI... export PINENTRY_USER_DATA=USE_CURSES=1 ...but that's not much better. I tried to write an Expect script with autoexpect, but curses makes a mess of the Expect code. I don't want to send the PIN to the clipboard and retrieve it with CTRL-V, as that's not a good place for it to be, even temporarily. Any ideas? -- Florin Andrei http://florin.myip.org/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: key length/size RSA discussion/recommendations in the wiki
On Wednesday 29 October 2014 22:18:13 Peter Lebbing wrote: On 2014-10-29 21:49, ved...@nym.hush.com wrote: Surely Peter knows this too ;-) More likely 128 was a typo for the more common older RSA key of 1028 ... No, I'm using a strict definition of brute force. For p = 2^63 to 2^64-1 For q = 2^63 to 2^64-1 If p * q == n: Break Next Next If anything then I'd do For p = 2^63 to 2^64-1 If n modulo p == 0: Break Next q = n / p which is O(n^(1/2)), but IMO still brute force (even in your strict definition), while yours is O((n^(1/2)^2) = O(n). brute force doesn't mean that you have to use the most naïve algorithm. I don't feel the method outlined by Rob is still brute force. That brute actually is using his brain. Possibly his brain resembles a sieve, but still :). Am I too strict? Actually, that brute doesn't seem to be using his brain. If he'd use his brain then he'd use he fists to brute force the secret out of you. ;-p Regards, Ingo 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
