Re: The meat with multiple PGP subkeys
On Wed, Jun 18, 2003 at 03:47:01PM +0200, Stefan Kelm wrote: David, A reasonable question would be Why don't all the PKS operators replace their server with SKS or something else?. I don't have a good answer to that. It's certainly been asked.[3] ...and has been answered a number of times. The thing is (and most people seem to forget about this now and then) that most, if not all, of the pgp.net server operators do run their servers in their spare time. Since pksd has a long history of not being overly stable one is happy once the server is up and running. Thus, the never-change-a-running-system paradigm is being lived in this realm. These servers are *broken*, and harming the use of PGP. Countless FAQs and other documents extol the keyserver network, and so new PGP users try it and get their keys eaten. One would hope that never-change-a-running-system wouldn't apply when the running system was actively causing damage. It's not just subkeys: PKS allows for a number of denial of service attacks against keys stored in it. It's a question, but the way I see it, if a keyserver operator doesn't want to fix critical bugs for fear of messing with a stable system, then just turn the thing off. That's stable too, and doesn't harm anyone. At least now there is subkeys.pgp.net so users can ignore the servers that aren't being fixed (and we just have to educate everyone to use it). David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
MD4 collision reproduced
I have reproduced both MD4 collisions from the recent paper. The example given had endian problems similar to those noted by Eric Rescorla for the sorta-MD5 collision. Also similar to Eric's results, the hash value (while a collision) does not match what the authors give in the paper. Example one: $ od -tx1 file1.bin 000 83 9c 7a 4d 7a 92 cb 56 78 a5 d5 b9 ee a5 a7 57 020 3c 8a 74 de b3 66 c3 dc 20 a0 83 b6 9f 5d 2a 3b 040 b3 71 9d c6 98 91 e9 f9 5e 80 9f d7 e8 b2 3b a6 060 31 8e dd 45 e5 1f e3 97 08 bf 94 27 e9 c3 e8 b9 100 $ od -tx1 file2.bin 000 83 9c 7a 4d 7a 92 cb d6 78 a5 d5 29 ee a5 a7 57 020 3c 8a 74 de b3 66 c3 dc 20 a0 83 b6 9f 5d 2a 3b 040 b3 71 9d c6 98 91 e9 f9 5e 80 9f d7 e8 b2 3b a6 060 31 8e dc 45 e5 1f e3 97 08 bf 94 27 e9 c3 e8 b9 100 $ cmp file1.bin file2.bin file1.bin file2.bin differ: char 8, line 1 $ openssl md4 file1.bin file2.bin MD4(file1.bin)= 4d7e6a1defa93d2dde05b45d864c429b MD4(file2.bin)= 4d7e6a1defa93d2dde05b45d864c429b Example two: $ od -tx1 file1.bin 000 83 9c 7a 4d 7a 92 cb 56 78 a5 d5 b9 ee a5 a7 57 020 3c 8a 74 de b3 66 c3 dc 20 a0 83 b6 9f 5d 2a 3b 040 b3 71 9d c6 98 91 e9 f9 5e 80 9f d7 e8 b2 3b a6 060 31 8e dd 45 e5 1f e3 97 40 c2 13 f7 69 cf b8 a7 100 $ od -tx1 file2.bin 000 83 9c 7a 4d 7a 92 cb d6 78 a5 d5 29 ee a5 a7 57 020 3c 8a 74 de b3 66 c3 dc 20 a0 83 b6 9f 5d 2a 3b 040 b3 71 9d c6 98 91 e9 f9 5e 80 9f d7 e8 b2 3b a6 060 31 8e dc 45 e5 1f e3 97 40 c2 13 f7 69 cf b8 a7 100 $ cmp file1.bin file2.bin file1.bin file2.bin differ: char 8, line 1 $ openssl md4 file1.bin file2.bin MD4(file1.bin)= c6f3b3fe1f4833e0697340fb214fb9ea MD4(file2.bin)= c6f3b3fe1f4833e0697340fb214fb9ea David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
On Tue, Sep 14, 2004 at 10:31:11AM +0200, Eugen Leitl wrote: I'm looking for (cheap, PCI/USB) hardware to store secrets (private key) and support crypto primitives (signing, cert generation). It doesn't have to be fast, but to support loading/copying of secrets in physically secure environments, and not generate nonextractable secret onboard. Environment is OpenBSD/Linux/OpenSSL/gpg. Since your environment includes GPG, then I think the OpenPGP smartcard meets pretty well what you are requesting. Combine it it with a USB smartcard reader, and the card becomes USB, too ;) http://www.silicon-trust.com/pdf/secure_8/48_ppc.pdf http://www.g10code.de/p-card.html David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: PGP master keys
On Wed, Apr 26, 2006 at 09:53:27PM -0400, Steven M. Bellovin wrote: In an article on disk encryption (http://www.theregister.co.uk/2006/04/26/pgp_infosec/), the following paragraph appears: BitLocker has landed Redmond in some hot water over its insistence that there are no back doors for law enforcement. As its encryption code is open source, PGP says it can guarantee no back doors, but that cyber sleuths can use its master keys if neccessary. What is a master key in this context? It sounds rather like a misunderstanding/mangling of PGP's Additional Decryption Key feature. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Fri, Sep 15, 2006 at 08:49:31PM +1200, Peter Gutmann wrote: When I fired up Firefox a few minutes ago it told me that there was a new update available to fix security problems. I thought, Hmm, I wonder what that would be It's interesting to note that we now have fixes for many of the OSS crypto apps (OpenSSL, gpg, Firefox GPG was not vulnerable, so no fix was issued. Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Sat, Sep 16, 2006 at 05:35:27AM +1200, Peter Gutmann wrote: David Shaw [EMAIL PROTECTED] writes: Incidentally, GPG does not attempt to parse the PKCS/ASN.1 data at all. Instead, it generates a new structure during signature verification and compares it to the original. How does it handle the NULL vs.optional parameters ambiguity? GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On Sat, Sep 16, 2006 at 12:35:08PM +1000, James A. Donald wrote: -- Peter Gutmann wrote: How does [GPG] handle the NULL vs.optional parameters ambiguity? David Shaw: GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. That is correct. OpenPGP passes the hash identification in the OpenPGP data as well as encoded in ASN.1 for the PKCS-1 structure. Since there is another source for the information, it is unnecessary to generate or parse ASN.1. In the case of GPG specifically (other implementations may do the same, but I can't say for sure), all ASN.1 data is hardcoded opaque strings. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Macgpg-users] GPGMail Snow Leopard
On Aug 28, 2009, at 8:25 PM, R.A. Hettinga wrote: ...and now GPG. So, Snow Leopard is crypto-less? To be strictly accurate, the problem is with GPGMail, the plugin that integrates GPG with Apple's Mail application (as Mail internals changed significantly between Leopard and Snow Leopard). GPG itself seems to work just fine under Snow Leopard, albeit on the command line. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Wikileaks video crypto.
On Apr 9, 2010, at 3:06 PM, Perry E. Metzger wrote: Earlier this weeks, Wikileaks released of video of an incident involving an Apache helicopter which killed two Reuters reporters and a number of bystanders in Iraq. A number of the reports surrounding the release claim that the video was decrypted by Wikileaks. Indeed, Wikileaks requested supercomputer time via twitter and other means to decrypt a video, see: http://twitter.com/wikileaks/status/7530875613 The video was apparently intentionally given to Wikileaks, so one can't imagine that the releasing parties would have wanted it to be unreadable by them (or that any reasonable modern cryptosystem would have be crackable). What, then, does the decryption claim mean here. Does anyone know? According to an interview with Julian Assange (one of the Wikileaks founders) at http://www.sueddeutsche.de/politik/740/507892/text/ , the decryption was essentially passphrase guessing. From Google Translate: He and a team of cryptographers had then worked for about three months out. The aim was to find among a few million of the most likely the correct passwords. See also http://www.youtube.com/watch?v=7QEdAykXxoM around the 1:22 mark. For what it's worth, the original encrypted file (encrypted with OpenSSL's 'enc' tool it seems) is claimed to be at http://leaks.telecomix.org/cm.rda. They do not provide the passphrase that managed to decrypt it. David - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
