Mailing List Archive: Little help please...

Little help please...

May 20, 2005, 12:24 PM

Post #1 of 9 (2694 views)

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?

Thanks in advance.

Tod

gcc 4.0.0
libgcrypt.so.11.2.0
libgpg-error.so.0.1.3

Re: Little help please... [ In reply to ]

wren at hunt

May 22, 2005, 5:39 AM

Post #2 of 9 (2650 views)

Permalink

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.

--

Cheers!

J. Wren Hunt
Cambridge, MA. USA

------------
"I have never killed anyone, but I have read some obituaries with some
satisfaction." - Clarence Darrow.

+------------------------------------------------------------------+
| v-card http://wrenhunt.homelinux.org/data/wren.vcf |
| x.509 http://wrenhunt.homelinux.org/data/thawte_wren_hunt.cer |
| OpenPGP ADF5 1432 A59E 8F4D 4AE7 4DFE 03FA 91E1 4A24 D6F4 |
+------------------------------------------------------------------+

Re: **SPAM** Re: Little help please... [ In reply to ]

tthomas at chubb

May 23, 2005, 6:46 AM

Post #3 of 9 (2646 views)

Permalink

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

Re: **SPAM** Re: Little help please... [ In reply to ]

wk at gnupg

May 23, 2005, 7:09 AM

Post #4 of 9 (2649 views)

Permalink

On Mon, 23 May 2005 09:46:23 -0400, Tod Thomas said:

> err = gcry_cipher_setkey(hd, key, keylen);

Use a fixed key for testing, like

err = gcry_cipher_setkey(hd, "123456789abcdef0", 16 );

> gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen(ciphertext));

This won't work: You can't use strlen on CIPHERTEXT becuase that one
is binary.

Shalom-Salam,

Werner

Re: **SPAM** Re: Little help please... [ In reply to ]

tthomas at chubb

Jun 1, 2005, 4:09 AM

Post #5 of 9 (2657 views)

Permalink

Werner Koch wrote:
> On Mon, 23 May 2005 09:46:23 -0400, Tod Thomas said:
>
>
>>err = gcry_cipher_setkey(hd, key, keylen);
>
>
> Use a fixed key for testing, like
>
> err = gcry_cipher_setkey(hd, "123456789abcdef0", 16 );

This triggered something that led me to solve my problem. My key length
was too short, for some reason I thought the key length was variable.
Oddly though, none of the API calls flagged me for an invalid key length...

>>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen(ciphertext));
>
>
> This won't work: You can't use strlen on CIPHERTEXT becuase that one
> is binary.

Won't it? All strings ultimately are just binary data.

>
> Shalom-Salam,
>
> Werner

Thanks for your help.

Re: **SPAM** Re: Little help please... [ In reply to ]

bradh at frogmouth

Jun 1, 2005, 4:18 AM

Post #6 of 9 (2658 views)

Permalink

On Wed, 1 Jun 2005 21:09 pm, Tod Thomas wrote:
> >>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen
> >>(ciphertext));
> >
> > This won't work: You can't use strlen on CIPHERTEXT becuase that one
> > is binary.
>
> Won't it? All strings ultimately are just binary data.
But binary data will contain arbitrary nulls. strlen just looks for the first
one.

Brad

Re: Little help please... [ In reply to ]

tthomas at chubb

Jun 1, 2005, 8:11 AM

Post #7 of 9 (2650 views)

Permalink

Brad Hards wrote:
> On Wed, 1 Jun 2005 21:09 pm, Tod Thomas wrote:
>
>>>>gcry_cipher_decrypt(hd,decryptedtext,strlen(ciphertext),ciphertext,strlen
>>>>(ciphertext));
>>>
>>>This won't work: You can't use strlen on CIPHERTEXT becuase that one
>>>is binary.
>>
>>Won't it? All strings ultimately are just binary data.
>
> But binary data will contain arbitrary nulls. strlen just looks for the first
> one.
>
> Brad

I was wondering about that. What is the accepted way to gather the
'length' of a binary value like this? sizeof()?

Re: Little help please... [ In reply to ]

wk at gnupg

Jun 1, 2005, 9:44 AM

Post #8 of 9 (2636 views)

Permalink

On Wed, 01 Jun 2005 11:11:59 -0400, Tod Thomas said:

> I was wondering about that. What is the accepted way to gather the
> 'length' of a binary value like this? sizeof()?

You need to track the length somewhere.

Salam-Shalom,

Werner

Re: Little help please... [ In reply to ]

tthomas at chubb

Jun 1, 2005, 9:51 AM

Post #9 of 9 (2639 views)

Permalink

Werner Koch wrote:
> On Wed, 01 Jun 2005 11:11:59 -0400, Tod Thomas said:
>
>
>>I was wondering about that. What is the accepted way to gather the
>>'length' of a binary value like this? sizeof()?
>
>
> You need to track the length somewhere.
>
>
> Salam-Shalom,
>
> Werner
>
>

Ok, thanks.

Mailing List Archive

Mailing List Archive

Attached Files: