Re: Debian encouraging use of 4096 bit RSA keys

2010-09-15 Thread Werner Koch
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

2009-03-03 Thread Werner Koch
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

2008-05-30 Thread Werner Koch
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)

2008-02-10 Thread Werner Koch
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

2008-01-31 Thread Werner Koch
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

2007-12-14 Thread Werner Koch
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

2006-02-15 Thread Werner Koch
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

2006-02-15 Thread Werner Koch
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

2006-02-14 Thread Werner Koch
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

2006-02-14 Thread Werner Koch
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

2006-02-14 Thread Werner Koch
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

2006-02-14 Thread Werner Koch
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

2006-02-12 Thread Werner Koch
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: long-term GPG signing key

2006-01-17 Thread Werner Koch
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

2005-12-14 Thread Werner Koch
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?

2005-09-13 Thread Werner Koch
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

2005-09-02 Thread Werner Koch
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

2005-08-31 Thread Werner Koch
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

2005-01-06 Thread Werner Koch
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)

2004-09-16 Thread Werner Koch
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?

2004-01-09 Thread Werner Koch
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?

2004-01-09 Thread Werner Koch
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?

2003-10-21 Thread Werner Koch
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

2003-06-08 Thread Werner Koch
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]