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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
. 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
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
23 matches
Mail list logo
