Re: Debian encouraging use of 4096 bit RSA keys
On Tue, 14 Sep 2010 17:01, h...@debian.org said: I'd appreciate some input from this list about the Debian bias towards 4096 RSA main keys, instead of DSA2 (3072-bit) keys. Is it justified? We have made RSA the default in GnuPG for three reasons: First, DSA 1024 is only supported by more recent versions of OpenPGP implementations whereas RSA is supported for 10 years now with any sane key size. Second, we want to support SHA2 et al as soon as possible; this is not possible with DSA-1024. Third, DSA signing is fast (DSA-3072 is about 7 times faster than RSA-4096) however verification is much slower (~15 times). Given that for most use cases verification is the most prominent operation (think only of checking hundreds of key signatures per key), this is for what we want to optimize. OTOH, DSA vs. RSA is not the real question. I have not seen a threat model for DD keys. I would claim that the best way to attack Debian's code signing is to take over a developer's box and make use of his/her key [1]. With ~ 1000 developers and thus at least this number of boxes and keys this is a by far an easier way for malice actions than even to think about how to break RSA-2048. I doubt that this situation will change in the next 10 years. These keys are used as KSK, as gpg will happily attach subkeys to them for the grunt work... Right, but than you should take the primary key offline or put it on a smart card - this removes the option to attack the primary key on the developer's box. And if one of the subkeys has been compromised it is very easy to replace that subkey. Salam-Shalom, Werner [1] An even easier way is to subvert the upstream source. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: X.509 certificate overview + status
On Mon, 2 Mar 2009 17:35, marcus.brinkm...@ruhr-uni-bochum.de said: Ubuntu comes with dumpasn1. There are also quite a few libraries. You may also import the certificate into GnuPG (gpgsm --import foo) and run gpgsm --dump-cert to get a human readable printout. Example: $ gpgsm --dump-cert 0x39F4F81B /home/foo/.gnupg/pubring.kbx --- ID: 0x39F4F81B S/N: 01D8 Issuer: CN=12R-CA 1:PN,O=Bundesnetzagentur,C=DE Subject: CN=TeleSec PKS SigG CA 17:PN,O=Deutsche Telekom AG,C=DE sha1_fpr: 13:0C:16:2D:91:68:7C:E0:AE:95:6F:11:08:34:3A:26:39:F4:F8:1B md5_fpr: D7:2B:65:D3:E6:5C:54:DB:B7:4A:47:49:6E:CF:36:F1 certid: D6C0C14EE753E3D147C0827A4C8D579F130DEFD4.01D8 keygrip: EC4EC0D13B47680C28869929D76B3357838CEC11 notBefore: 2007-11-08 09:22:57 notAfter: 2012-01-01 12:00:00 hashAlgo: 1.2.840.113549.1.1.13 (sha512WithRSAEncryption) keyType: 2048 bit RSA subjKeyId: 57A001BB58498529AEE9DFAD6810FA056F5F3A9B authKeyId: [none] authKeyId.ki: 04DE9D7FDF437289BA694901F4E84928DE02196F keyUsage: certSign extKeyUsage: [none] policies: 1.3.36.8.1.1 chainLength: 0 crlDP: ldap://ldap.nrca-ds.de:389/CN=CRL,O=Bundesnetzagentur,C=DE,dc=ldap,dc=nrca-ds,dc=de?certificateRevocationList;binary?base?objectClass=cRLDistributionPoint issuer: none authInfo: 1.3.6.1.5.5.7.48.1 (ocsp) http://ocsp.nrca-ds.de:8080/ocsp-ocspresponder subjInfo: [none] extn: 1.3.6.1.5.5.7.1.3 (qcStatements) [12 octets] extn: 1.3.6.1.5.5.7.1.1 (authorityInfoAccess) [62 octets] extn: 1.3.6.1.4.1.8301.3.5 (validityModel) [14 octets] CERTID and KEYGRIP are GnuPG specific. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: The perils of security tools
On Wed, 28 May 2008 10:34, [EMAIL PROTECTED] said: Yes. Still, some people are using fopen/fread to access /dev/random, which does pre-fetching on most implementations I saw, so using open/read is preferred for using /dev/random. It is not an implementaion issue but a requirement of the C standard. To avoid buffering use setvbuf (fp, NULL, _IONBF, 0); right after the fopen. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: TLS-SRP TLS-PSK support in browsers (Re: Dutch Transport Card Broken)
On Thu, 7 Feb 2008 16:37, [EMAIL PROTECTED] said: I don't have any idea why or why not, but all they can release now is source code with #ifdef openssl = 0.9.9 ... do PSK stuff ... #endif, The last time I checked the Mozilla code they used their own crypto stuff. When did they switched to OpenSSL and how do they solve the GPL/OpenSSL license incompatibility? Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fixing SSL
On Thu, 31 Jan 2008 03:04, [EMAIL PROTECTED] said: If you want a public example of client certificate usage: https://secure.cacert.org/ (You need a (free) client certificate from www.CAcert.org to be able to access Which has the problem that you may use any certifcate you ever created wit cacert.org to log in. Even certificates created for demo purposes with published private keys. That was the case up until a year ago; I don't know whether this has been changed. I was a bit surprised about such a security flaw. Salam-Shalom, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: More on in-memory zeroisation
On Thu, 13 Dec 2007 21:11, [EMAIL PROTECTED] said:
volatile char buf[SIZE];
/* ... do stuff with buf ... */
memset(buf, 0, sizeof(buf));
This has the little disadvantage that you need to check the attributes
of BUF first and that you can't immediately see what the memset is used
for. For a long time we use the macros below to document the intention
and to make sure that the compiler does not do any harm:
/* To avoid that a compiler optimizes certain memset calls away, these
macros may be used instead. */
#define wipememory2(_ptr,_set,_len) do { \
volatile char *_vptr=(volatile char *)(_ptr); \
size_t _vlen=(_len); \
while(_vlen) { *_vptr=(_set); _vptr++; _vlen--; } \
} while(0)
#define wipememory(_ptr,_len) wipememory2(_ptr,0,_len)
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz.
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, 14 Feb 2006 13:00:33 -0500, Steven M Bellovin said: Let me suggest a C-compatible possibility: pass an extra parameter to the library routines, specifying a procedure to call if serious errors occur. If that pointer is null, the library can abort. I agree. However the case at hand is a bit different. I can't imagine how any application or upper layer will be able to recover from that error (ENOENT when opening /dev/random). Okay, the special file might just be missing and a mknod would fix that ;-). Is it the duty of an application to fix an incomplete installation - how long shall this be taken - this is not the Unix philosophy. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Tue, 14 Feb 2006 15:53:39 -0500, John Denker said: It is straightforward but laborious to simulate exception-throwing in C: extern int errno; /* try some stuff */ if (errno) return; /* return immediately on any error */ Except that this does not work. ERRNO gets set by most calls only on error so if everything went fine in the try ssome stuff you get random results. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Sun, 12 Feb 2006 19:33:07 -0800 (PST), David Wagner said: Of course, it would be better for a crypto library to document this assumption explicitly than to leave it up to users to discover it the hard way, but I would not agree with the suggestion that this exit before Actually libgcrypt exactly does this. I have not looked at the postfix code under question but it sounds like stderr has beend duped to /dev/null and no log handler has been registered (e.g. to divert logging to syslog). Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Sun, 12 Feb 2006 23:57:42 -, Dave Korn said: :-) Then what was EINVAL invented for? [ Then for what was assert invented for? ] Really it's never ok for anything, not even games, and any program that fails to check error return values is simply not properly coded, full stop. I agree. But the reality is not that of the text books. But abort()-ing in a library is also a big problem, because it takes control away from the main executable. That can be a massive security vulnerability on Windows. If you can get a SYSTEM-level service that Huh? According to ISO C and POSIX abort raises SIGABRT and the default action is abnormal *process termination* - if your view is that process termination takes away control from the main executable I wonder how a file can control a process (unless the kernels plays nasty games with on demand paging). To my limited Windows experience abort() does terminate the process. I have ported quite some Unix applications nativly to Windows and never got in semantic problems you describe. Anyway, Windows is strange (atexit lists per DLL and such) but Libgcrypt is not really supported there. ... receive request from client ... fail to service it because libgcrypt returns errors.. return error to caller ... rather than for it to abort. Being in an insane state libgcrypt can't assure that this main loop will continue to run - the stack might already be corrupted. We don't know and thus assert(!fubar). I'm afraid I consider it instead a weakness in your API design that you have no way to indicate an error return from a function that may fail. By design there can't be any error. If there is an error something really strange has occured, like improper chrooting. Perhaps libgcrypt could call abort in debug builds and return error codes in production builds? Your joking right? I am usually quite sure that no attacker has made it to one of the machines used for debugging. Outside in the Internet wilderness I should then switch off all protection? That is like wearing a hard hat in bed and take it off at the construction site. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Mon, 13 Feb 2006 11:29:00 +0100, Simon Josefsson said: That /dev/random doesn't exist seem like a quite possible state to me. Running Linux this is not possible because /dev/random is guarenteed to be available. Further, a library is not in a good position to report errors. A users will sit there wondering why Postfix, or some other complex I don't know where Postfix dumps the error messages from Libcrypt: fd = open( name, O_RDONLY ); if( fd == -1 ) log_fatal (can't open %s: %s\n, name, strerror(errno) ); I guess you need to blame postfix for this. recommendation to avoid GnuTLS because libgcrypt calls exit suggest that the Postfix developers didn't care to investigate how to use GnuTLS and libgcrypt properly. So I don't think there is any real So may I conclude that it is actually Good Thing that in this case libgcrypt refrained from continuing to preserve the caller from false security. I'd say that the most flexible approach for a library is to write thread-safe code that doesn't need access to mutexes to work properly. Yes. We discussed this already at length at more appropriate places. That seem like a poor argument to me. It may be valid for embedded devices, but for most desktop PCs, Linux should provide a useful /dev/urandom. I can only tell what Ted told me years ago. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Mon, 13 Feb 2006 03:07:26 -0500, John Denker said: That might lead to an argument in favor of exceptions instead of error codes, along the following lines: -- Naive code doesn't catch the exception. However (unlike returned error codes) this does not cause the exception to be lost. -- The exception percolates up the call-tree until it is caught by some non-naive code (if any). -- If all the code is naive, then the uncaught exception terminates the process ... to the delight of the exit on error faction. However (!!!) unlike a plain old exit, throwing an exception leaves the door open for non-naive code to implement a nuanced response to the exceptional condition. Actually the plain C similar thing is done for an internal error: SIGABRT is raised and the top level code (or in theory any layer in between) may catch it and try to continue. Okay, this won't work in practise because signal handling between independent developed code (libraries) is guaranteed not to work correctly. And yes, we need to discuss whether whether a failed open should abort or exit. As of now it does an exit and not an abort() but I won't insist on this. Again, enough false dichotomies already! Just because error codes are open to abuse doesn't mean exiting is the correct thing to do. For Libgcrypt's usage patterns I am still convinced that it is the right decision. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: GnuTLS (libgrypt really) and Postfix
On Sun, 12 Feb 2006 13:46:05 -0500, John Denker said: That is a remarkably unprofessional suggestion. I hope the people who write software for autopilots, pacemakers, antilock brakes, etc. do not follow this suggestion. Thus my remark about a independend failsafe system. I strongly hope that for life critical systems nobody even things about throwing in a bunch of general purpose libraries and declares the task as done. Fortunately these systems have resource constraints so that such a solution won't come to mind anyway. First of all, impossible is the wrong word. If the condition s,impossible,not foreseen/tested/coded by the developer, previous tick's tasks are finished. What do you do, exit? If Yes. And one of the concurrent running system will take over. In 1969 this system used to be Armstrong, though. There are other stories like this, including funny (?) stories of what happens if exceptions are not handled so well. Terminating a process is a well handled exception. Think of hardware failure; continue while knowing that tehre is something really weird going on?? More generally: library routines should never exit. They almost If you are thinking of exit please mentally translate this to assert. Still believing one should never call assert(0) in a library? Nitpickers note: I can imagine a situation where the stack is so messed up that you can't thrown an exception or even return from Die as soon as you can; kill (getpid(),SIGKILL) might even be justified in such a situation. Try to make an attackers life as hard as possible. Yes, for life critical systems an attack scenario might be different to judge and thus the design needs to be different. Obviously I agree with Ben that that there is no way to know the current state if something went wrong in unexpected ways. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: X.509 / PKI, PGP, and IBE Secure Email Technologies
On Mon, 12 Dec 2005 10:59:05 -0600, Travis H said: Not to side track the discussion, but frequently I've heard PKI compared to PGP's model. Isn't PGP's trust model the same as everyone being their own CA? You need to clarify the trust model. The OpenPGP standard does not define any trust model at all. The standard merely defines fatures useful to implement a trust model. AFAIK, PGP provides two different trust models; with GnuPG you may also select between 4 trust models. However this is implementation specific and not part of the standard. The classic web of trust is just the commonly used one. It is a pity that many commonly used mail programs don't even make use of any real trust model but use the always trust model. The newer trust model pgp makes use of the advanced OpenPGP features and allows implementing a hierarchical model very similar to the X.509 one. In fact it is a superset of the X.509 model. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: ECC patents?
On Mon, 12 Sep 2005 11:58:14 +0300 (IDT), Alexander Klimov said: There is also work on ECC for gnupg http://www.g10code.de/tasklist.html#gcrypt-ecc Yes, there exists an implementation for an ECC implementation for GnuPG. The problem is that OpenPGP does not define ECC and thus it does not make much sense to have it there. We have not worked on the Libgcrypt integration of that code because there is not much need for ECC in general. The costs advantage of ECC smartcards is shrinking more and more and thus why should we bother to implement the host part of ECC just for fun and try convincing the OpenPGP WG to add ECC. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Tor security advisory: DH handshake flaw
On Thu, 01 Sep 2005 15:04:43 +0200, Simon Josefsson said: If you control the random number generator, you control which Miller-Rabin bases that are used too. Oh well, if you are able to do this you have far easier ways of compromising the security. Tricking the RNG to issue the same number to requests for the secret exponent of an DSA sign operation seems to be easier. Designing this fake random number generator is not trivial, and must likely be done separately for each crypto library that is used. If software only used prime numbers that came with a prime certificate, you combat this attack. Here it would be easier to add a backdoor to the prime certificate check than to implement a fake RNG. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Fwd: Tor security advisory: DH handshake flaw
On Mon, 29 Aug 2005 17:32:47 +0200, Simon Josefsson said: which are Fermat pseudoprime in every base. Some applications, e.g. Libgcrypt used by GnuPG, use Fermat tests, so if you have control of the random number generator, I believe you could make GnuPG believe it has found a prime when it only found a Carmichael number. 5 Rabin-Miller tests using random bases are run after a passed Fermat test. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL/TLS passive sniffing
On Wed, 5 Jan 2005 08:49:36 +0800, Enzo Michelangeli said: That's basically what /dev/urandom does, no? (Except that it has the undesirable side-effect of depleting the entropy estimate maintained inside the kernel.) This entropy depletion issue keeps coming up every now and then, but I still don't understand how it is supposed to happen. If the PRNG uses a It is a practical issue: Using /dev/urandom to avoid waiting for a blocked /dev/random will let other processes wait infinitely on a blocked /dev/random. The Linux implementation of /dev/urandom is identical to /dev/random but instead of blocking, (as /dev/random does on a low entropy estimation) it continues to give output by falling back to a PRNG mode of operation. For services with a high demand of random it is probably better to employ its own PRNG and reseed it from /dev/random from time to time. Salam-Shalom, Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: pci hardware for secure crypto storage (OpenSSL/OpenBSD)
On Wed, 15 Sep 2004 16:30:54 +0100, Ian Grigg said: There is a device that is similar to those characteristics: http://woudt.nl/epass-pgp/ http://www.financialcryptography.com/mt/archives/000201.html The advantage of the OpenPGP card is that is is a specification that it is open and ready for everyone to implement. No proprietary strings attached as usual in the smartcard business. So go write an application according to the specs and it will, run with any card compliant with the spec. Any vendor may implement this spec on his card. Whether you do this on a slow 4 Euro chip or a fast 8 Euro chip or on an iButton is up to you. Our card is just one implementation of the spec using an expensive chip. Werner - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
On Thu, 27 Nov 2003 11:30:45 -0500, Ian Grigg said: such keys to give them extra time to revoke the keys. However one addresss was from killfile.org and actually a mail-news gateway ... Was said key was being used to sign messages of some authentication importance? I don't know. art. Werner, if you come across any cases where people are incovenienced beyond the normal key code replacement issues, I'd hope you can share the anecdotes with us (suitably anonymised as appropriate)? Regarding this ElGamal sign bug, the only thing I heard of were a very few Debian developers who lost all their key signatures and have to start again gathering new signatures from their co-Debian developers. However there was no anger about this it sounds more like, oops, I shoot myself into my foot with my self-build secure thing. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Problems with GPG El Gamal signing keys?
On Mon, 1 Dec 2003 11:20:10 -0800, Anton Stiglic said: From: Ralf Senderek [EMAIL PROTECTED] Maybe we can learn that code re-use is tricky in cryptography: indeed, if the signing function and encryption function did not use the same gen_k function, the author of the code would have done the optimization that But duplicates the lines of code and thus introduces another source of errors. Its aghrd to tell what ebtter. Given that the algorithms for signing and encryption are really different (compared to RSA) it might have been better to use separate source files for ElGamal-signing and ElGamal-encryption and don't view them as similar. g = 2 is safe but insecure for signatures... It's just simpler to have two distinct pairs of keys. Sure, that's what OpenPGP strongly suggests. However ElGamal signing stems from a time before OpenPGP when I tried to replace RSA by ElGamal and keeping most of the PGP2 format (rfc1991) in place. By the way, is the paper by Phong Q. Nguyen describing the vulnerability available somewhere? Or maybe someone could describe the cryptanalysis I don't know, please ask him. Phong dot Nguyen at ens.fr. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: WYTM?
On Tue, 21 Oct 2003 15:02:14 +1300, Peter Gutmann said: Are there any known servers online that offer X.509 (or PGP) mechanisms in their handshake? Both ssh.com and VanDyke are commercial offerings so it's not possible to look at the source code to see what they do, and I'm not sure Joel N. Weber II developed PGP patches for OpenSSH: http://www.red-bean.com/~nemo/openssh-gpg/ and I am pretty sure that he has a server up somewhere. Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Nullsoft's WASTE communication system
On Thu, 5 Jun 2003 19:52:28 -0700, Kevin Elliott said: Out of curiosity, how does the performance of AES compare to Blowfish (seeing as how performance would be the obvious advantage of Blowfish Encrypt/decrypt time for Libgcrypt: Algo ECB CBC CFB CTR -- --- --- --- --- 3DES1120ms 1130ms 1140ms 1170ms 1200ms 1190ms 1410ms 1400ms BLOWFISH 350ms 340ms 370ms 380ms 430ms 430ms 630ms 630ms AES 290ms 310ms 340ms 360ms 410ms 410ms 620ms 620ms AES256 400ms 410ms 440ms 470ms 510ms 510ms 730ms 720ms over 3DES)? Also are there any patent/license constraints on AES (the There are no constraints on AES usage. Shalom-Salam, Werner -- Werner Koch [EMAIL PROTECTED] The GnuPG Expertshttp://g10code.com Free Software Foundation Europe http://fsfeurope.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
