Re: [cryptography] OpenPGP in Python: Security evaluations?
On Fri, 12 Jun 2015 12:39, li...@infosecurity.ch said: Regarding GPGME, is it really exec()uting the gpg binary or is it calling directly the gpg as a library? Sure it does fork/exec. However, gpgsm is run as a co-process and thus there is only one fork/exec for a bunch of operations (descriptor passing is use for the bulk of data). That can also be implemented for gpg but we have not yet seen a use case which really demands that - thus changing this for gpg has a low priority. (gpgsm uses this because it is newer than libgpgme and thus could be designed with the co-process in mind). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] OpenPGP in Python: Security evaluations?
On Thu, 23 Apr 2015 08:25, li...@infosecurity.ch said: Unluckily PyMe is unmaintained and there's no major software using GPGMe interface. On my Debian box I see ~50 direct dependencies including several MUAs and Jabber clients. KDE uses the C++ wrapper in several packages. libgmime is used by 13 tools and libs python-gpgme is used by 6 tools and libs python-pyme by 3 tools ruby-gpgme by 2 tools. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PGP word list
On Sun, 22 Feb 2015 13:19, f...@deneb.enyo.de said: An option to spell out the digits and letters in a hex fingerprint would be a good start, so that you end up with some sort of Something like this? $ gpg -k --with-icao-fingerprint 1e42b367 pub dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31] Key fingerprint = 8061 5870 F5BA D690 3336 86D0 F2AD 85AC 1E42 B367 Eight Zero Six One Five Eight Seven Zero Foxtrott Five Bravo Alfa Delta Six Nine Zero Three Three Three Six Eight Six Delta Zero Foxtrott Two Alfa Delta Eight Five Alfa Charlie One Echo Four Two Bravo Three Six Seven uid [ unknown] Werner Koch w...@gnupg.org Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] PGP word list
On Thu, 19 Feb 2015 11:04, i...@iang.org said: I just realised one barrier -- language. It uses the English language, and PGP might be stronger in Europe than in the anglo world. Right. I recall that this has been discussed in the OpenPGP WG years ago. IIRC, the conclusion was that the international spelling alphabet has been developed just for this purpose and that all kind of shortcut word lists would lead to more confusion than plain spelling of hex digits. Recall that the spelling alphabet works well under a bad S/N-ratio and thus also between speakers of different mother tongue. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email encryption for the wider public
On Fri, 19 Sep 2014 06:57, g...@toad.com said: She can send you email at de...@ihtfp.com once, and when your replies all come from: From: Derek Atkins lkjasdflksdlkjp2338tnlsdfh848492-hds8f...@ihtfp.com then when she replies to you, she'll be sending encrypted emails. But The same can be achieved with a separate mail header for the key and a local association of key and mail address for future communication (which you need for the above scheme also). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Cryptography] Email encryption for the wider public
On Fri, 19 Sep 2014 12:37, givo...@gmx.com said: for a key in a key server (keystore). but, automatically sending a separate header sounds, er...automatic, transparent to the user. and lets the system do the work. long, more than 10 digits, Actually such a header and an I-D exists for close to a decade https://datatracker.ietf.org/doc/draft-josefsson-openpgp-mailnews-header/ Example: OpenPGP: id=1E42B367; url=finger:w...@g10code.com Maybe it can be extended with a use=always parameter. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] technical question about gpg on debian/sid
On Tue, 15 Oct 2013 18:10, fu...@yuggoth.org said: Also, to bring this further onto topic, any critiques of the above linked articles are of interest to me. I'm currently in the process of drafting some similar recommendations for another large free There is a simple rule for best practices: Use the defaults - they are there for a reason. We try to provide best interoperability by updating the defaults as need arise and if most installed versions support these algorithms. Noteworthy changes in version 1.4.10 (2009-09-02) Noteworthy changes in version 2.0.13 (2009-09-04) * 2048 bit RSA keys are now generated by default. The default hash algorithm preferences has changed to prefer SHA-256 over SHA-1. 2048 bit DSA keys are now generated to use a 256 bit hash algorithm (SHA-224 was used before). Regarding SHA256, the default preferences (as used for sign+encrypt) for a new key are for quite some time: /* The default hash algo order is: SHA-256, SHA-1, SHA-384, SHA-512, SHA-224. Ordering SHA-1 before SHA-384 might be viewed as a bit strange; it is done because we expect that soon enough SHA-3 will be available and at that point there should be no more need for SHA-384 etc. Anyway this order is just a default and can easily be changed by a config option. */ If you want to write up something, I suggested to mention the creation of a revocation certificate. Unfortunately gpg does not yet do this automatically. And most important, stress the importance to somehow keeping the box secure so not to fall prey to the standard attacks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] blinding is in libgcrypt but NOT in gnupg?
On Fri, 23 Aug 2013 05:56, j...@spaz.org said: I found it in libgcrypt. I don't understand why it's not in gnupg. Becuase in GnuPG 2.x all crypto operations are done by Libgcrypt. It looks to my untrained eye that gnupg and libgcrypt had a common ancestor, but i'm not sure when that was. Anyway, here is what I The NEWS file has this information. Noteworthy changes in version 1.1.3 (2001-05-31) * First release of Libgcrypt which is a result of splitting GnuPG into into libgcrypt and GnuPG. Given that this is about a concrete implementation, you may want to continue the discussion at gnupg-devel@ Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] LeastAuthority.com announces PRISM-proof storage service
On Thu, 15 Aug 2013 13:11, wasabe...@gmail.com said: To: and From: headers leak the emails/identity of communicating parties, but it's not the only place that happens. I've never used PGP but I've used OpenPGP allows sending messages without information on the used keys (e.g. gpg --throw-keyids). Folks using many secret keys need to have a bit more patience due to the required trial decryptions. keywrap structure. If the email is present, it will leak even if To/From were protected somehow. Even if the email is not present, maybe the cert A mail can easily be wrapped into an message/rfc822 container along with more innocent outer headers. This would allow to keep on using the existing mail infrastructure. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ElGamal Encryption and Signature: Key Generation Requirements?
On Wed, 19 Dec 2012 10:00, a...@cypherspace.org said: probably is heading towards the computional in feasibility, so the only real chance is if people would communicate the p_i values (or the seed for re-generating them, perhaps.) Actually GnuPG tracked those values up to version 1.4.1 in the secring.gpg. Thus it would have been possible to publish them. During these ~7 years there as never been a demand for them and thus we eventually stopped storing them. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Thu, 16 Feb 2012 11:00, f...@deneb.enyo.de said: In X.509, certification signatures cover the value of the notAfter attribute. If I'm not mistaken, this is true for V3 keys as well. Right. They are also covered by the fingerprint (The fingerprint used for X.509 is only a de-facto standard). However, when a V4 key is signed, the certification signature does not cover the expiration date. The key holder (legitimate or not) can Wrong. Look at my key: :public key packet: version 4, algo 17, created 1199118275, expires 0 pkey[0]: [2048 bits] pkey[1]: [224 bits] pkey[2]: [2046 bits] pkey[3]: [2048 bits] :user ID packet: Werner Koch w...@g10code.com :signature packet: algo 17, keyid F2AD85AC1E42B367 version 4, created 1199118881, md5len 0, sigclass 0x13 digest algo 11, begin of digest 2a 29 hashed subpkt 27 len 1 (key flags: 03) hashed subpkt 9 len 4 (key expires after 11y2d12h35m) [...] subpkt 16 len 8 (issuer key ID F2AD85AC1E42B367) The signature packet is the certification for the key and user id. A signature packet consist of subpackets which may either be hashed or unhashed. Hashed subpackets are part of the signed material and thus can't be removed. You are right that RFC4880 does not demand that the key expiration date is put into a hashed subpacket. But not doing so would be stupid. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Thu, 16 Feb 2012 13:03, bmoel...@acm.org said: Oh, in this case it's a self-signature. Werner, the problem (aka feature) is that expiry according to self-signatures isn't carried forward into third-party certification signatures -- so if an attacker gets hold of the That depends on how the third party does the key-signing. OpenPGP allows to provide an expiration date for the third party certification (aka key signing). This solves the problem of OpenPGP CAs - it does not solve the general problem of CAs at all. The commonly used WoT semantics don't require you to check the expiration date of a passport or driver license either. The signature expiration dates, as used by some folks, try to add some extra value into their key signatures for no good reason: Either the identity has been verified or not - the identity will not change after the expiration date. Even if you change your name later, back at the key signing time you were known under the certified name. necessarily cover the expiry date, and unlike X.509 where certifications always come with *some* notAfter date.) A better name for notAfter would be payableBefore. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Duplicate primes in lots of RSA moduli
On Thu, 16 Feb 2012 12:30, bmoel...@acm.org said: I call it a protocol failure, you call it stupid, but Jon calls it a feature (http://article.gmane.org/gmane.ietf.openpgp/4557/). It is a feature in the same sense as putting your thumb between the nail head and the hammer to silently peg up a picture frame. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, 28 Oct 2011 14:03, t...@panix.com said: So this appears to be basically a smartcard and USB smartcard reader built into the same frob. I can probably find a way to put it within Right. Unfortunately, it also appears to be unbuyable. I tried all three sources listed on the crypto-stick.org website yesterday: two were out of stock, while the third said something along the lines of They are manually assembled thus you won't see much in stock. Your better choice is to buy one of the Zeitcontrol OpenPGP cards and an SCM USB stick style reader [1] - you get exactly the same. Salam-Shalom, Werner [1] Never buy an Omnikey card reader unless you can want to use it only on Windows. Only the Windows drivers allows the use of 2k keys. The omnikey chip supports Extended Length APDUs only via proprietary and undocumented features. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Fri, 28 Oct 2011 11:10, mar...@martinpaljak.net said: PKCS#11 but also open source drivers (also free, in the sense of free software vs open source software) is as good excuse to reject PKCS#11 In 99% percent of all cases Open Source and Free Software describe software distributed under the same terms. Thus it is not helpful to distinguish between them. And common sense tells that using PKCS#11 is a better option than not using it at all or inventing a 15th standard [1]. Well, GnuPG had support for several cards before there was any _working_ pkcs#11 driver for any available card on non-Windows platforms. Recall that not too long ago pkcs#11 was an interface consisting of some basic core functions with a lot of required proprietary extensions and many of them even shared the same function pointer slot. Meanwhile major players don't use it anymore for interop purposes but defined their own high level standard - similar to what GnuPG did. Anyway, we had this discussion on the gnupg lists often enough that it does not make sense to repeat our views here again. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
On Thu, 27 Oct 2011 11:15, mar...@martinpaljak.net said: I don't know about PGP(.com), but GnuPG is picky about hardware key containers. Things like PKCS#11. For the records: That is simply not true. We only demand an open API specification for the HSM because we don't want to support binary blob pkcs#11 drivers. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
