Another bug in RIPEM?

Thread View: alt.security.ripem

4 messages

[T] Back to Threads [V] Tree View [G] Group Articles

4 total messages Started by Darrell Long Mon, 11 Jan 1993 00:44

#46

Author: Darrell Long
Date: Mon, 11 Jan 1993 00:44

22 lines
1171 bytes

If I set the RIPEM_KEY_TO_PRIVATE_KEY environment variable, I can encrypt but
not decrypt.  For example,

sequoia [1]% printenv
HOME=/home/darrell
LOGNAME=darrell
USER=darrell
...
RIPEM_PUBLIC_KEY_FILE=/home/darrell/lib/keys/public
RIPEM_PRIVATE_KEY_FILE=/home/darrell/lib/keys/private
RIPEM_KEY_TO_PRIVATE_KEY=XYZZY
sequoia [2]% ripem -e -m encrypted -r darrell@sequoia | ripem -d
Hello world!
Private key could not be decrypted with this password.

But if I don't set it, and type the password each time, everything works fine:

sequoia [1]% ripem -e -m encrypted -r darrell@sequoia | ripem -d
Hello world!
Enter password to private key: 
Enter password to private key: 
Hello world!

Re: Another bug in RIPEM?

#48

Author: Marc VanHeyningen
Date: Mon, 11 Jan 1993 03:08

23 lines
1574 bytes

Thus said darrell@cse.ucsc.edu (Darrell Long):
>If I set the RIPEM_KEY_TO_PRIVATE_KEY environment variable, I can encrypt but
>not decrypt.  For example,
>
>sequoia [2]% ripem -e -m encrypted -r darrell@sequoia | ripem -d
>Hello world!
>Private key could not be decrypted with this password.

Hmmm.... curious.

The fact that it complains "private key could not be decrypted with this
password" does not necessarily mean that the error was in the "ripem -d"
call; it probably was in the first call to RIPEM to encrypt.  Most likely,
there was something about the passphrase (spaces, shell metacharacters,
etc.) that didn't get to RIPEM unchanged.  Was "XYZZY" the passphrase?

I can't duplicate this bug; what does it show if you turn on debugging
output (-D 5)?
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted
"I cannot recommend this candidate too highly or say enough good things about
him.  In my opinion you will be lucky to get him to work for you.  I urge you
to waste no time making him an offer.  No one would be better for the job."

Re: Another bug in RIPEM?

#49

Author: Danny Guy Frezza
Date: Mon, 11 Jan 1993 03:32

39 lines
1596 bytes

In a previous article, darrell@cse.ucsc.edu (Darrell Long) says:

>If I set the RIPEM_KEY_TO_PRIVATE_KEY environment variable, I can encrypt but
>not decrypt.  For example,
>
>sequoia [1]% printenv
>HOME=/home/darrell
>LOGNAME=darrell
>USER=darrell
>...
>RIPEM_PUBLIC_KEY_FILE=/home/darrell/lib/keys/public
>RIPEM_PRIVATE_KEY_FILE=/home/darrell/lib/keys/private
>RIPEM_KEY_TO_PRIVATE_KEY=XYZZY
>sequoia [2]% ripem -e -m encrypted -r darrell@sequoia | ripem -d
>Hello world!

	Just curious.  Did you type a <control> Z after "Hello world"?

I tried this on my 386, msdos version, and had no problem.
I also tried it from a file, no problem also.
Hmm..

>Private key could not be decrypted with this password.
>
>But if I don't set it, and type the password each time, everything works fine:
>
>sequoia [1]% ripem -e -m encrypted -r darrell@sequoia | ripem -d
>Hello world!
>Enter password to private key: 
>Enter password to private key: 
>Hello world!
>
>

-- 

Dan Frezza
Internet: bz223@Cleveland.Freenet.Edu

Re: Another bug in RIPEM?

#52

Author: Mark Riordan
Date: Mon, 11 Jan 1993 03:40

8 lines
739 bytes

Darrell Long (darrell@cse.ucsc.edu) wrote:
: If I set the RIPEM_KEY_TO_PRIVATE_KEY environment variable, I can encrypt but
: not decrypt.  

This bug was fixed (by Louis A. Mamakos) in RIPEM 1.0.1.
I just tried it on my system and it works now.

Mark

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads