It looks like one of the changes between 0.9.8h and 0.9.8i broke
apps/dsa.c. In particular, this block:
BIO_printf(bio_err,read DSA key\n);
{
EVP_PKEY*pkey;
if (pubin)
pkey = load_pubkey(bio_err, infile, informat, 1,
Jeffrey Altman wrote:
...
The Windows section looks like it needs a close review.
...
Indeed it does.
A confession/rant: the Windows relevant content of the User Gide has
all been second-hand since some six months ago. I own two copies of MS
Windows (3264 bit), each purchased at full
Isn't it obvious? You broke the SHA algorithm in the client, causing it to
RSA sign the wrong value. When the server checks the signature, it fails
because it is a signature of the wrong thing.
But I have tested the algorithm. It gives identical hash values. I just want to
know if there is
On December 8, 2008 06:41:58 am Vishnu Param wrote:
Isn't it obvious? You broke the SHA algorithm in the client, causing it
to RSA sign the wrong value. When the server checks the signature, it
fails because it is a signature of the wrong thing.
But I have tested the algorithm. It gives
On Mon, Dec 08, 2008, Vishnu Param wrote:
But I have tested the algorithm. It gives identical hash values. I just want
to know if there is something that I am missing.
As I understand it, the hash function hashes the values and puts them into
the SHA_CTX variable. From my observation, the
Dr. Steven Henson wrote:
What you put in SHA_CTX should be irrelevant as long as the entire context is
contained in a flat structure (so it can be memcpy'ed). If you hang structures
off the end that will cause problems unless you allow for that at the EVP
level with the copy function.
I'd
