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: questions about RNGs and FIPS 140
On Wed, 25 Aug 2010 22:37, travis+ml-cryptogra...@subspacefield.org
said:
> 1) Is Linux /dev/{u,}random FIPS 140 certified?
I am nor sure whether it is already certified. However a FIPS mode was
added to Linux featuring an FIPS approved ANSI X9.31 PRNG instead of the
/dev/random. /dev/random is still used for initial seeding.
Salam-Shalom,
Werner
--
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 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 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 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 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 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 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 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: GnuTLS (libgrypt really) and Postfix
On Sat, 11 Feb 2006 12:36:52 +0100, Simon Josefsson said: > 1) It invoke exit, as you have noticed. While this only happen > in extreme and fatal situations, and not during runtime, > it is not that serious. Yet, I agree it is poor design to > do this in a library. I disagree strongly here. Any code which detects an impossible state or an error clearly due to a programming error by the caller should die as soon as possible. If you try to resolve the problem by working around it will increase code complexity and thus error won't be detected. (Some systems might provide a failsafe mechanism at a top layer; e.g. by voting between independed developed code). Sure, for many APIs it is posssible to return an error code but this requires that the caller properly checks error codes. We have all seen too many cases were return values are not checked and the process goes ahead assuming that everything went well - this might be okay for games but definitely not for cryptographic applications. Libgcrypt tries to minimize these coding errors; for example there are no error returns for the RNG - if one calls for 16 bytes of random one can be sure that the buffer is filled with 16 bytes of random. Now, if the environemnt is not okay and Libgcrypt can't produce that random - what shall we do else than abort the process. This way the errors will be detected before major harm might occur. It is the same rationale why defining NDEBUG in production code is a Bad Thing. > 2) If used in a threaded environment, it wants to have access to > thread primitives. The primary reason was for RNG pool locking > (where it is critical), but I think the primitives are now used > in other places too. GnuTLS is thread agnostic, so it can't > initialize libgcrypt properly. Against our advise Nikos rejected to implement a proper initialization. Libraries and threading is actually a deep problem. It usually works well on GNU/Linux systems but this is more of coincidence than by design. We did quite some research on this and experimented with different ways of automagically initializing the thread primitives correctly; they all fail either at runtime or create headaches when trying to write proper build rules. The current approach is by far the most flexible and safest. But yes, the fact that one library needs an initialization can't be hidden from the application even if the application is using the lib only indirectly (Foo->OpenLDAP->GnuTLS->Libgcrypt). Background: The problem stems from the fact that there are more than one thread implementations available and used. Mixing them in one process cries for problems. There are quite a couple of libs taking the putatively easy approach of using pthreads. Applications using another thread implementaion (e.g. Pth to make auditing possible) will then sooner or later run into grave problems. > list. I think the Linux /dev/urandom implementation is sub-optimal. This is known since Ted Ts'o wrote /dev/random and justified by requirement of the Linux hackers to keep the memory use by a minimal Linux build low. Shalom-Salam, Werner - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: long-term GPG signing key
On Thu, 12 Jan 2006 00:48:05 -0600, Travis H said: > All it really does is crudely limit the quantity of data sent under > that key, which is little to none anyway. And it has the advantage that people will stop sending encrypted mail to this key after the expiration date. Comes handy if you forgot your passphrase or lost physical access to the key. 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 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: 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 Wed, 26 Nov 2003 18:24:12 -0500, Perry E Metzger said: > Some notes have been floating around claiming that there are bugs in > GPG's use of El Gamal keys. For example, see: Yes, that is true. The message was intended for the known owners of such keys to give them extra time to revoke the keys. However one addresss was from killfile.org and actually a mail-news gateway ... Yes, yes, I should have removed ElGamal signing key support back in 1998 when there was no more need for it. I recall that some folks begged me not to do that and I took the wrong decision. 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: Draft Edition of LibTomMath book
On Fri, 27 Jun 2003 14:02:30 +1200, Peter Gutmann said: > the GMP source code to know what it does (GMP is a special case, being a > general bignum library but with an implicit acknowledgement that it's going to > end up used for crypto as well, although there are some missing primitives Does the proprietary SSH still use GMP? I know no other major crypto apps using GMP for big number math. A problem with GMP is that it heavily uses alloca() and thus it is not that hard to find traces of secrets in the core. 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]
Re: The meat with multiple PGP subkeys
On Tue, 17 Jun 2003 23:42:13 +0200, martin f krafft said: > an unusable public key. It only seems to work if they use modern > software and obtain my key from keyserver.kjsl.com:11371 or the You may also want to use subkeys.pgp.net. These are servers running software not eating keys. > - What is the problem with multiple subkeys? pksd used to have only a simple hack to support *one* subkey but bo revocation for them etc. If they encounter a key with an "unknown" structre they start to eat packets or swap them around. Updated pksd versions are much better and won't eat them anymore. However due to the syncronisation they can't do much about already garbled keys except for removing invalid parts. > - Are they in accordance with the RFC (2440)? Sure. > - Are others experiencing these problems, and how do you deal with > them? I have these problems for may years now and as a workaround I use the X-Request-PGP header to point to a valid source of my key. > - Is there a solution in the works? There is a couple of new keyserver software actually in use but not yet widespread enough. subkeys.pgp.net is a goog start. > - If not, has anyone already thought about how to solve this mess? All keyserver operators should update to the new pksd or even better use one of the modern servers. 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]
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]
