In all honesty I would recommend against getting a 64-bit certificate. And I
would recommend just as strongly against a 512-bit certificate. There's 2
large reasons for this. First the 64-bit, the RSA DES Challenge III taught
us that using second rate, 3 year old technology, in a relatively
- Original Message -
From: Francis DeLaMaza [EMAIL PROTECTED]
BTW, what is AES?
- Original Message -
From: Francis DeLaMaza [EMAIL PROTECTED]
Any disadvantages to AES? Who is
developing it? Opensource?
AES is the soon to be government standard titled Advanced Encryption
You should not be able to use an expired/revoked certificate to successfully
complete an SSL handshake. This actually occurs out of band, the certificate
has the information in it for any individual to contact a server and verify
the validity of it. However I know Microsoft utilities have a
- Original Message -
From: "Dr S N Henson" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Joseph Ashwood wrote:
Does anyone have some code onhand that will take a PKCS 12 file, lookup
a
known name, grab a DSA key and hand it back?
[snip most of what I said]
Alternately, does a
And let me say it again, this time with a bit more information.
Windows runs on x86, which is little endian, Linux I assume you are also
running on little-endian (x86). Solaris I assume you are running on
UltraSPARC which if I remember correctly is big-endian. You are not
transferring your keys
Ok, now we're getting somewhere. It's a misunderstanding of what the values
mean (I'm going to over simplify some to make the points clearer).
When an SSL connection is 40-bit, it means that the negotiated key size is
40-bits.
When you ask to generate an X-bit certificate, that refers to the
It's ok, we all make mistakes. I've had similar bugs, probably 3 dozen
times, with various amounts of time to find them.
Joe
- Original Message -
From: "Bruker, Ohad" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 16, 2001 2:09 PM
Subject: RE: symmetric
First a bit of background. RSA is this:
p,q primes
N=pq
e=prime that is not a factor of p-1 or q-1 and not equal to p or q
d = e^-1 mod (p-1)(q-1)
public key = {e,N}
private key = {d, N}
Encryption = X = M^e mod N
Decryption = M = X^d mod N
The e-value you see in the call is the value e above.
- Original Message -
From: "Bruker, Ohad" [EMAIL PROTECTED]
All the basic stuff you mentioned is implemented right.
It is already *WORKING* on Linux and Windows platforms without any
problems.
I encounter this problem probably because Solaris does not support random
device !!!
The
Just a guess, but a fairly educated one, try setting flen to 1 byte (or even
1 bit) smaller than the key. What I suspect is happening is you are
sometimes trying to encrypt values that are larger than the modulus so
you're getting a modular reduction of the value encrypted.
If all you're callling is DH_generate_key(...) then it should create
different keys. That function call only generates the public and private
keys. What you need to do is:
DH_generate_parameters(...)
transfer the parameters between machines so that they are both working in
the same field
'm calling the DH_compute_key(...) after sharing the DH public
key both sides.
The symmetric keys are already produced successfully on Windows and Linux.
Thanks, Ohad.
-Original Message-----
From: Joseph Ashwood [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 14, 2001 6:14 PM
To: [EMAIL
I've found a problem with BN_mod_inverse, in particular when it is called
many times in quick succession when verifying DSA signatures. Originally
this showed up when use DSA_do_verify, so I wrote my own, and I've isolated
the problem as being in BN_mod_inverse. It seems to only occur on about
13 matches
Mail list logo
