Re: BoF at FOSDEM ?
On Sat, 1 Feb 2014 14:13, mar...@martinpaljak.net said: Too bad I missed. Where did you get with the ECC discussion? I merely reported about the status and that I think it is better to wait a few weeks until the I-D for the new curves is more complete. Then we can start to implement that. Kristian reported that the keyservers do not yet fully support ECC (required for keyid and fingerprints) but that should not be a showstopper. Deployment of new keyserver code is happening much faster than in the past. We have been about 12 people at the BoF and from their comments I read that non-NIST curves should be the default. But first of all I need to fix some things I broke in the last weeks. We also talked about a possible 1.5 release to make 1.4 maintenance easier by switching to Libgcrypt. This would save use from maintaining a completely detached branch of crypto code for 1.4 and allow to add ECC support to GnuPG-1. 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: BoF at FOSDEM ?
On 01/02/14 14:13, Martin Paljak wrote: Too bad I missed. Where did you get with the ECC discussion? Correct me if I'm wrong but I understand that 2.1 is planned for the end of summer, and that currently there is a wait for all the haggling and standardisation work around ECC (see https://irtf.org/cfrg mailing list), which is close to done, but there's still debate about point compression format. The time frame also coincides with the last (possibly relevant / possibly FUD) ECC patents expiring. Cheers, arne -- Arne Renkema-Padmos Doctoral researcher CASED, TU Darmstadt @hcisec, secuso.org ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
openpgp card and basiccard RNG
Hello, Aparrently the OpenPGP card is based on BasicCard [1] and from the BasicCard FAQ [2] I read: For Enhanced BasicCards, the card has no hardware generator. The Enhanced BasicCards contain a unique manufacturing number which cannot be read from outside the card. The Rnd function uses this number to generate random numbers which are different for each card. For Professional and MultiApplication BasicCards, the random number is generated by use of a hardware random number generator. Does anybody know which version of BasicCard is used for the OpenPGP cards distributed by KernelConcepts.de? If it is the Enhanced version, does the use of a pseudorandom generator pose a security risk? Cheers, Konstantinos 1. http://www.basiccard.com/index.html?news.htm 2. http://www.basiccard.com/engfaq.htm -- |/ |/ Konstantinos koukopou...@gmail.com |\ |\ Koukopoulos http://kouk.surukle.me VSRE messages are welcome*, Thanks! * for more information see: http://vsre.info http://vsre.info/ ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
making the X.509 infrastructure available for OpenPGP
Hello, I would like to say first that my X.509 understanding is orders of magnitude lower that that of OpenPGP. So I hope this makes sense to you... This idea came to my mind while I was wondering why several CAs offer free (but rather useless...) certificates for X.509 but not for OpenPGP. Whatever they do with X.509 can be done with OpenPGP, too (e.g. setting an expiration date for the signature). How much effort can it be to offer both? Then I realized that they could do that but that a CA signature for an OpenPGP certificate is rather useless in today's situation: Most of the value of an X.509 certification is the pre-installed root CA pool. A certification by a non-pre-installed CA is typically less useful than an OpenPGP certification. Now my point: Keys can be converted from one format to the other. The fingerprint changes but obviously the keygrip doesn't. I believe it would make a lot of sense to create a connection between gpg and gpgsm and point gpgsm to the OS's and / or browser's root certificate pool. Then a CA could offer its certificate in OpenPGP format (even conforming to some new standard which makes it easier to detect this special kind of certificate e.g. by using a comment or signature notation pointing to the related X.509 certificate), and GnuPG could easily realize that it is the same key. This would relieve the user from the hard decision whether a certificate is valid (the CAs OpenPGP certificate in this case). The user would just have to decide (like with any other OpenPGP certificate) whether he wants to trust this CA (and how much). By doing so the pre-installed CA pool would become valuable for OpenPGP, too, and it would make sense for the CAs to offer certifications for OpenPGP certificates, too. Maybe there are other reasons for some CAs, too. But I assume this would be rather little effort and could close much of the gap to S/MIME's convenience. 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
