Richard Levitte via RT wrote: > I've figured it out. The problem only occurs when the first passphrase > is longer than the second. In your example, you will see that the > output key (tpk.pem) really is protected with the passphrase > "bbbbbaaaaaaa" (5 bs followed by 7 as). Thanks, I would NEVER have figured that out :-) that's the point, isn't it... This showed up the way it did because I use a machine-generated storage passphrase while the private keys are escrowed, and either decrypt them or re-encrypt them with a pass phrase given on the pick-up-your-key page, and the machine-generated one is 12 characters long. Perhaps it wasn't such a bad implementation after all: if my users had used a reasonable pass phrase (more than 12 characters long) it wouldn't have bitten them at all. It was only my half-arsed testing with "bbbbb" as a pass phrase that brought the bug out.
> As you may have figured out by now, it's a NUL termination problem in > the BIO gets routine that's called (looks like buffer_gets() in > bf_buff.c. I'm working on it. -- Charles B (Ben) Cranston mailto: [EMAIL PROTECTED] http://www.wam.umd.edu/~zben ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
