[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Blowfish still good enough?



On Friday 30 December 2005 00:08, Damien Miller wrote:
> On Thu, 29 Dec 2005, Travers Buda wrote:
> > The key schedule in both is _much_ faster than Blowfish.
>
> That is not a feature, at least not in the contexts where we use
> blowfish most.

Yes, I realize that. I did not say fast key schedules are desireable. 
You're jumping the gun.

> guess what? We have used long salts with Blowfish passwords since at
> least 1999.

I was unaware of this. I shall read that paper before I continue 
replying. 

> If there is a use of Blowfish in OpenBSD that you think is
> inappropriate then please send diffs.

I'm not concerned with the use of Blowfish in the password file, rather 
I think it's the best choice. What I think is irrelevent here 
really--the facts speak for themselves. 

What I'm concerned about is the use of Blowfish in vm.swapencrypt.enable 
and vnconfig -k. Just because its use in the password file is genius, 
does not necessairly mean it would make for the best option elsewhere. 

What I'm worried about is that several devs implemented this fantastic 
password file scheme, then perhaps (no accusations yet) got deluded 
that Blowfish is the greatest thing since sliced bread and decided it's 
fit for everything--including their laundry. 

> If there is a use of Blowfish in OpenBSD that you think is.
> inappropriate then please send diffs.  

I am in the process of learning various languages, starting with C. 
(Crypto still affects everyone--including those who don't program or 
are cryptographers.) I also would hope that things would be evaluated 
for problems before solutions are applied.

I'm just looking for some reassurances, Mr. Miller. Docs are preferable, 
unfortunately the informative link you sent me earlier does not cover 
the use of Blowfish elsewhere in OpenBSD. That's what I've been looking 
for; I had to turn here since I could not find such info. 

I also knew I'd get lambasted on misc since the prospect of a lack of 
documentation of OpenBSD is preposterous. 

Travers