**SPAM** Re: Little help please...

Tod Thomas tthomas at chubb.com
Mon May 23 15:46:23 CEST 2005


J. Wren Hunt wrote:
> Tod Thomas wrote:
> 
>>I have two test programs, one encrypts, the other decrypts.  When I pipe
>>a string to the encryption program and pipe its output to the decryption
>>program I get the original string back.  This is on Redhat 8.
>>
>>I took the code from the encryption program and wrote a server plugin to
>>perform password encryption to replace an out of the box hashing
>>algorithm.  The defined need is to be able to construct our own
>>encryption that can be decrypted later on another server.  This server
>>encryption plugin works and was been developed on a Solaris 8 box.
>>
>>The problem is I can't get the Sun server encrypted password to decrypt
>>on the RH box.
>>
>>I have debug statements that display the password both before and after
>>encryption and decryption, in both hex and binary.  The encrypted
>>password generated on the server side doesn't match its counterpart on
>>the RH side.
>>
>>Since I expected I would be able to just take the encrypted value on the
>>server side and decrypt it using the test decryption program I wrote I
>>suspected there was a problem in the server plugin.  So I added a call
>>to the decryption function there to display it to see if the password
>>was getting corrupted somehow.  It decrypted to the correct value.  So
>>now I'm stumped and have a couple of questions.
>>
>>Should this work?  Is it reasonable to believe I can decrypt a string
>>produced using the exact same setup (iv, key, mode, and algorithm) on
>>one platform (Solaris), on a different platform (RH)?  If not is there
>>another solution?
>>
>>This is the gcrypt developer's list, I couldn't find a gcrypt-user's
>>list.  Is this the best place to ask these types of questions?
>>
> 
> 
> Hi Tod!
> 
> Did you get this working yet? If not can you post a link to your code? I
>  can help test on different-endian platforms if you like.

Not yet.  I don't have a link I can post the code to at the moment.  I 
can summarize it real quick:


encode
-------

fread() the plaintext
err = gcry_cipher_open(&hd, GCRY_CIPHER_TWOFISH, GCRY_CIPHER_MODE_CFB, 
(unsigned int)NULL);
err = gcry_cipher_setkey(hd, key, keylen);
err = gcry_cipher_setiv(hd, NULL, 0);
err = 
gcry_cipher_encrypt(hd,ciphertext,MAXSIZE,plaintext,strlen(plaintext));
fprintf(stderr,"Resulting ciphertext (hex): ");
for(i=0;i<strlen(ciphertext);i++)
     fprintf(stderr,"%02X", ciphertext[i]);
fprintf(stderr,"\n");
printf("%s",ciphertext);


decode
------
fread() the encoded text
err = gcry_cipher_open(&hd, GCRY_CIPHER_TWOFISH, GCRY_CIPHER_MODE_CFB, 
(unsigned int)NULL);
err = gcry_cipher_setkey(hd, key, keylen);
err = gcry_cipher_setiv(hd, NULL, 0);
err = 
gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen(ciphertext));
printf("decrypted text            : %s\n", decryptedtext);


I made the IV NULL to simplify things.  In both instances the key is the 
same, again to keep things simple.  I chose 2fish encryption arbitrarily 
to make things easier also.

I've compiled both successfully on RH and Solaris.  The plugin displays 
its values in hex info as it encrypts and decrypts the password it is 
processing.

I've ported both test programs up to the Solaris box and get the same 
results - the server plugin's hex representation of the entered password 
matches the test encryption program's, but the hex representation of 
each program's resulting ciphertext doesn't match.  Does this eliminate 
endian-ness as the culprit?


Thanks for your help.  I can post the code to the list if necessary.

Tod



More information about the Gcrypt-devel mailing list