Blowfish still good enough?

[Travers Buda]

From the *I know I'm going to get lambasted* department, a subdivision of

*I'm an idiot,* under the jusrisdiction of *now I remember why I unsubscribed
from misc* comes this blather:

I'm not a cryptographer, but strong crypto (or the lack thereof) affects us
all in serious ways. As such, I was pondering whether or not it would be in
the interests of OpenBSD to use a different standard than blowfish--Twofish
and Rijndael.

There was a time when everyone thought DES was perfectly good encryption.
Then weaknesses were discovered in it. People still clung to DES even when the
weaknesses could be proved on paper. It took the EFF's DeepCrack, the DESCHALL
project, and then the former along with distributed.net's cracking of DES keys
to strike the final blow.

No known weaknesses exist in Blowfish, but that 64 bit block scares me.

It can't hurt to err on the side of caution. Thus, it would be a good idea to
consider using one of the 2nd round NIST finalists for the crypto in the base
system. Rijndael and Twofish seem to be the best candidates, due to their
efficiency (see http://www.schneier.com/paper-aes-comparison.html ) and
non-radical nature (twofish in particular.) Plus, they have been througly
scrutinized and are unencumbered.

The key schedule in both is _much_ faster than Blowfish. The password file and
others would require the use of salts in order to resist dictionary attacks,
especially of the time-space trade-off variety.
Bruce Schneier designed Blowfish, he also was one of the men behind
Twofish--which was designed to kick some butt in the AES competition. Besides,
if we use Twofish, we won't have to worry about getting a new mascot. We'll
just need an additional one.
Please, tell me I'm an idiot and Blowfish is the best choice for crypto. Then
I won't worry anymore.

[Martin Schröder]

Post by Travers Buda
Please, tell me I'm an idiot and Blowfish is the best choice for crypto. Then
I won't worry anymore.

You worry too much.

How much is the data worth you are protecting? And how long do
you want it to be protected? And what makes you think that
cracking crypto is the only way to get to the data?

Best
Martin

[Travers Buda]

If it is worth doing, it is worth doing right. While I'm always
impressed with the quality of OpenBSD, this matters most to me.

Post by Martin Schröder

Post by Travers Buda
Please, tell me I'm an idiot and Blowfish is the best choice for
crypto. Then I won't worry anymore.

You worry too much.
How much is the data worth you are protecting? And how long do
you want it to be protected? And what makes you think that
cracking crypto is the only way to get to the data?
Best
Martin

[Ted Unangst]

Post by Travers Buda
If it is worth doing, it is worth doing right. While I'm always
impressed with the quality of OpenBSD, this matters most to me.

and your concern is with blowfish in what context?

Post by Travers Buda

Post by Martin Schröder

Post by Travers Buda
Please, tell me I'm an idiot and Blowfish is the best choice for
crypto. Then I won't worry anymore.

You worry too much.
How much is the data worth you are protecting? And how long do
you want it to be protected? And what makes you think that
cracking crypto is the only way to get to the data?
Best
Martin

[Travers Buda]

Post by Ted Unangst

Post by Travers Buda
If it is worth doing, it is worth doing right. While I'm always
impressed with the quality of OpenBSD, this matters most to me.

and your concern is with blowfish in what context?

My concern is the strength of Blowfish--it's robustness--if someone with
a large amount of resources desired to crack it.

Yes, I suppose I do worry too much. A pilot won't fly a plane that he
know is unsafe, will he? I still would not mind a few words from those
people who decided Blowfish was the way to go because of A, B, and C.

[Ted Unangst]

Post by Travers Buda

Post by Ted Unangst
and your concern is with blowfish in what context?

My concern is the strength of Blowfish--it's robustness--if someone with
a large amount of resources desired to crack it.

then don't use it.

[Chris Cappuccio]

Post by Travers Buda
My concern is the strength of Blowfish--it's robustness--if someone with
a large amount of resources desired to crack it.

You mention that twofish is faster than blowfish. So, you would rather
make a brute force password attack easier?

[Blake Darche]

Post by Martin Schröder

Post by Travers Buda
Please, tell me I'm an idiot and Blowfish is the best choice for crypto. Then
I won't worry anymore.

You worry too much.

You can't worry too much. There is a saying: "Attacks always get
better; they never
get worse."

Post by Martin Schröder
How much is the data worth you are protecting? And how long do
you want it to be protected? And what makes you think that
cracking crypto is the only way to get to the data?

Good point. You can always get data another way.

Post by Martin Schröder
Best
Martin
--
http://www.tm.oneiros.de

Blake

[Damien Miller]

Post by Travers Buda
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.

Post by Travers Buda
The password file and
others would require the use of salts in order to resist dictionary attacks,
especially of the time-space trade-off variety.

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

http://www.openbsd.org/papers/bcrypt-paper.ps

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

-d

[Travers Buda]

Post by Damien Miller

Post by Travers Buda
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.

Post by Damien Miller
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.

Post by Damien Miller
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.

Post by Damien Miller
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

[Otto Moerbeek]

Post by Travers Buda

Post by Damien Miller

Post by Travers Buda
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.

Post by Damien Miller
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.

Post by Damien Miller
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.

Swapencrypt uses aes. Check /usr/src/sys/uvm/uvm_swap_encrypt.c

Post by Travers Buda
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 you do not trust us, why use OpenBSD?

Post by Travers Buda

Post by Damien Miller
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.

-Otto

[veins]

Post by Travers Buda
[...]
No known weaknesses exist in Blowfish, but that 64 bit block scares me.
[...]

Can you explain why it scares you ? I am not a cryptographer but I see
no reason why a cipher using
64 bit block size is scary, all of the attacks I can think of that are
tied to the block size are still not
practicable with a 64 bit block size (either they require too much
memory, too much time or too much
information). Maybe I am not thinking of something obvious, so please
correct me if i'm wrong.

Post by Travers Buda
It can't hurt to err on the side of caution. Thus, it would be a good idea to
consider using one of the 2nd round NIST finalists for the crypto in the base
system. Rijndael and Twofish seem to be the best candidates, due to their
efficiency (see http://www.schneier.com/paper-aes-comparison.html ) and
non-radical nature (twofish in particular.) Plus, they have been througly
scrutinized and are unencumbered.

Blowfish has also been scrutinized and analyzed (and for a longer time
than both Rijndael and Twofish), it
has proven to be strong and resistant, as well as efficient for most
needs. Also Rijndael being the standart
doesn't mean that it is the safest choice at all (not that i'm saying
its bad, im not a cryptographer), and
well Twofish sounds cool but why switch from a working solution to
another one, when there's no real need
for that time and effort consuming change ?

Post by Travers Buda
The key schedule in both is _much_ faster than Blowfish. The password file and
others would require the use of salts in order to resist dictionary attacks,
especially of the time-space trade-off variety.

That's not really an issue:
a- there's a paper about that somewhere on the website and if i recall
correctly, the openbsd blowfish-based
hash takes advantage of the fact that ks is time-consuming and with
some adaptations make it even more
time consuming so that an attack on the password file is a pain in
the ...
b- don't really remember the internals of blowfish but, can't subkeys be
precomputed ? I thought it was
doable for any cipher based on a Feistel network (I might be wrong,
but im not a cryptographer and its
over 7am after a sleepless night ;-)
d- people running OpenBSD on modern systems won't notice the overhead.
most people running OpenBSD
on older/slower boxen will actually find the ks quite fast ... after
they've waited ages when generating their
ssh keys :-)

[Travers Buda]

Post by veins

Post by Travers Buda
[...]
No known weaknesses exist in Blowfish, but that 64 bit block scares
me. [...]

Can you explain why it scares you ? I am not a cryptographer but I
see no reason why a cipher using
64 bit block size is scary, all of the attacks I can think of that
are tied to the block size are still not
practicable with a 64 bit block size (either they require too much
memory, too much time or too much
information). Maybe I am not thinking of something obvious, so please
correct me if i'm wrong.
Blowfish has also been scrutinized and analyzed (and for a longer
time than both Rijndael and Twofish), it
has proven to be strong and resistant, as well as efficient for most
needs. Also Rijndael being the standart
doesn't mean that it is the safest choice at all (not that i'm saying
its bad, im not a cryptographer), and
well Twofish sounds cool but why switch from a working solution to
another one, when there's no real need
for that time and effort consuming change ?

Yes, this entire thread may be moot. Why fix it if it ain't broken?
Well, we may not know that it is broken. We can only use our best
judgement--a matter of opinion sometimes. Ack.

Bruce Schneier designed Blowfish.
Bruce Schneier designed Twofish to be a sucessor to Blowfish.

Post by veins
Blowfish has also been scrutinized and analyzed (and for a longer
time than both Rijndael and Twofish)

Blowfish may be older, but I think that Twofish has been analyzed more
than Blowfish due to the NIST competition a few years back.

Post by veins
well Twofish sounds cool but why switch from a working solution to
another one, when there's no real need
for that time and effort consuming change ?

I agree, Blowfish is just fine in some applications. I don't know if
it's universal though. OpenBSD uses it almost universally.

I'm not saying OpenBSD should use Twofish. I'm asking wherether or not
OpenBSD should use Twofish.

Sweet dreams, veins

Travers

[Joachim Schipper]

Post by Travers Buda
I'm not a cryptographer, but strong crypto (or the lack thereof) affects us
all in serious ways. As such, I was pondering whether or not it would be in
the interests of OpenBSD to use a different standard than blowfish--Twofish
and Rijndael.
No known weaknesses exist in Blowfish, but that 64 bit block scares me.
It can't hurt to err on the side of caution. Thus, it would be a good idea to
consider using (...) Rijndael (or) Twofish.
Bruce Schneier designed Blowfish, he also was one of the men behind
Twofish--which was designed to kick some butt in the AES competition. Besides,
if we use Twofish, we won't have to worry about getting a new mascot. We'll
just need an additional one.

Looks like it ain't broke to me. Both MD5 and SHA-1 are beginning to
show their age, and there exist attacks that would, in some
circumstances, allow your TLA of choice to circumvent the protection
they should offer (most likely by faking signatures). In most instances
they are still perfectly acceptable ciphers, but I can see how one would
want to keep away from them.

I know that I've switched to something different for the few cases where
I make a GnuPG signature, take out MD5 if at all feasible, and try to
replace SHA-1 where this isn't too inconvenient.

On the other hand, I've not heard of any feasible attacks on Blowfish.
Which is not to say that Twofish might not be better, but it ain't
broke. Neither are MD5 or SHA-1, by the way.

All in all, I can think of better things to do...

Joachim

[Travers Buda]

Blowfish ain't broke. Yet. There was a time when everyone though MD5 was
good enough. Now there is code on the internet to produce meaningful
collisions. I bet a year or two from now pepople will laugh at the idea
of using it to secure anything. It is dying a slow death. Sorry!

It is my understanding that Blowfish's 64 bit block may make it more
vulnerable to cryptoanalysis than Twofish's 128. Whatever.

No point talking about a subject with a really thin line.

It is my opinion that OpenBSD lacks a good cryptographic disk solution.
That is just an opinion. Yes, I know, code is much more valuable.

I'm through.
Travers

Post by Joachim Schipper
Looks like it ain't broke to me. Both MD5 and SHA-1 are beginning to
show their age, and there exist attacks that would, in some
circumstances, allow your TLA of choice to circumvent the protection
they should offer (most likely by faking signatures). In most
instances they are still perfectly acceptable ciphers, but I can see
how one would want to keep away from them.
I know that I've switched to something different for the few cases
where I make a GnuPG signature, take out MD5 if at all feasible, and
try to replace SHA-1 where this isn't too inconvenient.
On the other hand, I've not heard of any feasible attacks on
Blowfish. Which is not to say that Twofish might not be better, but
it ain't broke. Neither are MD5 or SHA-1, by the way.
All in all, I can think of better things to do...
Joachim

[d***@uchicago.edu]

---- Original message ----

Date: Fri, 30 Dec 2005 01:27:42 -0800
Subject: Re: Blowfish still good enough?

Post by Travers Buda
My concern is the strength of Blowfish--it's robustness--if someone with
a large amount of resources desired to crack it.

You mention that twofish is faster than blowfish. So, you would rather
make a brute force password attack easier?

bingo! this is exactly why blowfish is a good encryption algorithm: it's very
strong against brute forcing since attempting each key requires 512 operations
to fill the S-boxes. i would be more worried about brute forcing than i would
cryptanalytic attacks, perhaps my confidence is misplaced :P.

if anybody had a reasonably large quantum computer, all of this would be
irrelevant. i sure hope that's not the case!

see http://groups.google.com/group/sci.crypt/msg/6f6e157149330057 for an opinion
of twofish.

[Dan Smythe]

Somebody please correct me if I'm wrong. Blowfish has
been extensively analyzed since 1993. It is believed
to be secure.

As far as the 64 bit blocks go: most solid encryption
programs generally use a block chaining mode, to group
multiple blocks together. Encrypt one block, XOR it
with the next, etc. Even if collisions were found in
the ciphertext, the most the attacker could deduce is
that they represent the same plaintext block. If the
attacker didn't previously know what that ciphertext
block meant, it wouldn't really do them any good.

I think Blowfish is a great choice for the encryption
algorithm. Besides, factor this into the mix: Blowfish
uses a key up to 448 bits. Twofish goes up to 256
bits, as does AES. AES may or may not have been broken
based on the XSL attack. So the key size is an
atvantage over Twofish, and the years of review makes
for an advantage over AES.
Just $16.99/mo. or less.
dsl.yahoo.com

[Travers Buda]

Well I was contemplating the error of my ways on this thread. I realized
that I was wrong. Blowfish's implementation is secure and efficient...
from a programmer's point of view.

A few hundred years ago everybody knew the Earth was the center of the
universe.
Then we knew that the most basic form of stuff (what we now know as
atoms) resembled chocolate chip cookies.
A hundred years ago, putting a man on the moon was inconcieveable.

The Nazis thought their Enigma machine was perfect.
The password file on *nix systems back in the day used to be
world-readable.
DES used to be considered strong crypto. The USA's National Bureau of
Standards standardized it. The National Institute of Standards and
Technology, which formerly was the NBS--the guys who decided DES was
good--also say that AES is safe now, too.

Imagine what we will know tomorrow. Just think about it, in a few
hundred years mankind may be able to zip around the universe at will.
It will never happen, you say. Science says it can't.
I can't recall how many sciences were later debunked. What makes ours
any better?

So what does this have to do with keeping your secrets safe? Well, it
occured to me that no crypto is perfect, as I hope everyone feels. To
keep those secrets safe, we don't need stronger crypto--we need more of
it.

Imagine a large (as in quantity) homogenous crop that a populated
country depends on to eat. If one virus comes along and kills off that
crop, then those people will suffer greatly. But, if those people
diversify their agriculture and have three crops, then that one virus
will not cause famine.

This can be applied to cryptography, and for my practical purposes,
cryptographic disks. Imagine the efficacy of taking at least three
radically different (from one another) forms of crypto and
superimposing those cryptographies on one another.

So, for instance you have the secret which you crypt with A, then crypt
it with sceme B, and finally C.

If weaknesses are found in one of those cryptographies (I'm confident of
this, it's what history teaches us) then scheme A and C are still
protecting that data.

Sure, it's slow, inefficient. But if you have need of storing data
securely, you should be able to sleep at night, knowing that you're as
protected as humanly possible. It's also really paranoid, a simpler
implementation which can be found everywhere will generally protect you
against say, laptop thieves. Yet, if it is worth doing, it is worth
doing right.

Doing it right involves obfusgating your data so that any attemts at
brute-forcing it would result in more meaningful data that could be
produced by a monkey on a typewriter typing for epoch or so (they say
that the monkey would eventually write Shakespere.)

Yes, I am _exaggerating_, but it's to prove my point.

There is no value in the second kick of a mule. Look at history, we need
to drop our arrogance that our cryptographies are strong. Then we need
to do the best job as humanly possible (if you wonder what this route
is, just remember--tinfoil hat paranoia) to keep information secret,
which I believe involves using different cryptographies for the same
set of data.

At the very least, the idea of diversification is good... the details
can be worked out later.

I'm not a programmer nor a cryptographer,
I'm a historian and philosopher, among a few other things.
That's why you should listen, since if you only speak to the
aforementioned types of people, your view of the world will remain
narrow--a narrow view of things is dangerous.

Travers K. Buda

[Said Outgajjouft]

Travies all crypto is breakable. The only demand on crypto is how long
in takes to break it. If it takes more than 5 years the military usually
thing its safe enough to use. Why, because after 5 years the information
is usually out of data.

But since you withhold so sensitive data I suggest you burn it up and only
remember it in your head than it should be safe enough for you.

Time after time you state you dont know anything about programming and
crypto still you bitch how the OpenBSD developer should develop the system.
If you dont like the way they have done it why dont you just send diffs
and correct their terrible mistakes. As the slogan goes for whiners on misc
SHUT UP AND CODE which you should know as an historian because you only
need to check past posts on the misc list .

But I guess a philosopher you will argue what SHUT UP really means and
we will see a flood of post about that on misc to.

[knitti]

please cut the trolling.

the problem is not, whether or not blowfish is secure enough.
the problem is that you HAVE NO FUCKING IDEA what you are talking
about, category-wise. you can't tell why blowfish could be bad. you
can't tell which one would be better, because you don't know why.
you can't suggest a design in which one could pull one crypto and
use another, let alone implementing it.

and no, combining crypto on top of each other doesn't make it
more secure per se. right now threats to our data is _not_ weak
algorithms, it is sometimes weak implementations (think e.g.
OS X file vault), and much more important, it is rubberhose
cryptoanalysis and social reasons which won't be solved technically.


--knitti

[Joachim Schipper]

Post by Travers Buda
Well I was contemplating the error of my ways on this thread. I realized
that I was wrong. Blowfish's implementation is secure and efficient...
from a programmer's point of view.
This can be applied to cryptography, and for my practical purposes,
cryptographic disks. Imagine the efficacy of taking at least three
radically different (from one another) forms of crypto and
superimposing those cryptographies on one another.
Sure, it's slow, inefficient.
At the very least, the idea of diversification is good... the details
can be worked out later.

You are right, *if* your data is of such a nature that it needs to be
kept secret for tens, likely hundreds of years. In that case, however,
extending the vnd(4) device to use, at least, AES as well should be
easy. (Not that I've looked at the code, but quite a few algorithms seem
to be in the kernel already, among them AES.)

For me, personally, I don't handle data that I'd be willing to have my
fingers broken for, so protecting the data better than myself makes
little sense.

That doesn't mean that your idea isn't at least theoretically sound -
and yes, implementing it would not necessarily be a bad idea (on a
guess, one might be able to layer svnd(4) devices, so only adding some
algorithms should be enough). That being said, I'm not convinced it has
priority.

Joachim

[Travers Buda]

Post by Joachim Schipper
You are right, *if* your data is of such a nature that it needs to be
kept secret for tens, likely hundreds of years. In that case,
however, extending the vnd(4) device to use, at least, AES as well
should be easy. (Not that I've looked at the code, but quite a few
algorithms seem to be in the kernel already, among them AES.)
For me, personally, I don't handle data that I'd be willing to have
my fingers broken for, so protecting the data better than myself
makes little sense.
That doesn't mean that your idea isn't at least theoretically sound -
and yes, implementing it would not necessarily be a bad idea (on a
guess, one might be able to layer svnd(4) devices, so only adding
some algorithms should be enough). That being said, I'm not convinced
it has priority.
Joachim

Other people than I agree, it does not need top priority. But then
again, all that is really in the eye of the beholder. That's why I
intend to try my hand at doing it.

Post by Joachim Schipper
more secure per se. right now threats to our data is _not_ weak
algorithms, it is sometimes weak implementations (think e.g.
OS X file vault), and much more important, it is rubberhose
cryptoanalysis and social reasons which won't be solved technically.
--knitti

Yes! That's what my e-mail was about. It spoke (now) not of weak
algorithms, but of weak implementations. I'm glad you agree with me
that the latter is our biggest threat.

Dick,
You said you would like to be able to select from various algorithms. I
don't know your motivation; perhaps you have a Hfin.
Would you like to work with me, then? Supporting more than one cipher in
svnd does somewhat fulfill my idea of diversification--users would not
have to wait for a patch and then patch, etc., if there were a problem
with one cipher. It would be a good place to start.

Good day to you all,
Travers Buda

[Ted Unangst]

Post by Travers Buda
The Nazis thought their Enigma machine was perfect.

Do you know why Enigma was broken? Primarily because the operators
didn't follow procedure and made a series of other mistakes ("This
doesn't seem too important"). As is typical, the problem was not with
the crypto, it was with the idiots using it.

[Will H. Backman]

Post by Ted Unangst

Post by Travers Buda
The Nazis thought their Enigma machine was perfect.

Do you know why Enigma was broken? Primarily because the operators
didn't follow procedure and made a series of other mistakes ("This
doesn't seem too important"). As is typical, the problem was not with
the crypto, it was with the idiots using it.

I guess any encryption algorithm is limited by entropy. Given that most
users choose bad passwords, the algorithm doesn't matter that much.
What is the point of trillions of possible keys when people choose from
only a few hundred thousand?

I'd just say "no" to any passwords.

[d***@uchicago.edu]

---- Original message ----

Date: Sun, 01 Jan 2006 10:39:02 +0100
Subject: Re: Blowfish still good enough?
Travies all crypto is breakable. The only demand on crypto is how long
in takes to break it. If it takes more than 5 years the military usually
thing its safe enough to use. Why, because after 5 years the information
is usually out of data.
But since you withhold so sensitive data I suggest you burn it up and only
remember it in your head than it should be safe enough for you.
Time after time you state you dont know anything about programming and
crypto still you bitch how the OpenBSD developer should develop the system.
If you dont like the way they have done it why dont you just send diffs
and correct their terrible mistakes. As the slogan goes for whiners on misc
SHUT UP AND CODE which you should know as an historian because you only
need to check past posts on the misc list .
But I guess a philosopher you will argue what SHUT UP really means and
we will see a flood of post about that on misc to.

LOL!

i agree that travers doesn't make a good case for why support for additional
ciphers should be added. it would, however, be nice to be able to select from a
number of ciphers for encrypted file system support via vnconfig. again, you've
made a good point: somebody has to SHUT UP AND CODE to get this done. this won't
be me doing this, but i'm just saying it would be nice to see even though i'm
totally confident in the safety of blowfish.

the main point that travers has made in several of his emails (besides the key
point that "he doesn't know what he's talking about") is that the block size of
64 bits worries him. since, AFAIK, blowfish is even less brute-forceable than
the rijndael competitors due to the key scheduling algorithm and design
considerations related to it, i assume travers' concern is vulnerability to
cryptanalytic attacks. is there a correlation between cryptanalytic
vulnerability and block size?

[Dan Smythe]

I certainly hope that if new ciphers are added to
svnd, that Blowfish is still included. Many of my
previous file systems use Blowfish, and it is my
preferred algorithm.
Just $16.99/mo. or less.
dsl.yahoo.com

[Sebastian Rother]

Post by Ted Unangst

Post by Travers Buda
The Nazis thought their Enigma machine was perfect.

Do you know why Enigma was broken? Primarily because the operators
didn't follow procedure and made a series of other mistakes ("This
doesn't seem too important"). As is typical, the problem was not with
the crypto, it was with the idiots using it.

Related to the Enigma:
They had to Write "Heil Hitler" or "HH" at the End of every message.
So it's a neat example for a known plaintext attack. :-))

related to svnds:
Yes OpenBSD uses Blowfish and yes it si secure and YES it could be blf
with 448Bit. But OpenBSD uses (as far as I know) just 128Bit.

Blowfish is secure but Twofish is faster and as secure as Blowfish.
At least if there some quant. computers 128Bit will not save ya day
anymore.
The question is not "Is blowfish still secure enought".
It is more: Why can't the user choose how strong the data will get
encrypted?

An ideal algorithm for user-accounts would be secure and slow as hell.
But then such an algorithm would just be usefull to protect the
user-passwords....

Blowfish is a good compromise but Twofish would be indeed also neat too
because it's faster (importent for data-encryption) in software then
AES (Rijandel).

And if I'm allowed to "wish" me something for next x-mas:
A better solution to encrypt whole disks would be nice.
Maybe also using the AES-Engine from the VIA CPUs for this job.
Or just a way to encrypt the disks where I could choose some parameters
of the algorithm (Bits, Rounds..)...

FreeBSD has a nice way (geom) to encrypt whole disks (just from the
point of the usebility).

Kind regards,
Sebastian

p.s.
Bruce Schneier wouldn't develop an algorithm if he would still think
that Blowfish (an algorithm from 1993 and puplished 1994) would still
be the best choice for the next 10-30 years.

[knitti]

Post by Sebastian Rother
Blowfish is secure but Twofish is faster and as secure as Blowfish.

wrong. apples are as fast as tables. bluefish encrypts faster than twofish.
don't know about rekeying etc.

Post by Sebastian Rother
At least if there some quant. computers 128Bit will not save ya day
anymore.

quantum computers are the real big buzzword to scare people into
irrational behaviour. nobody knows whether or when quantum computer
will be able to brute force 128 bit keys. and whether twofish will save you.

Post by Sebastian Rother
Blowfish is a good compromise but Twofish would be indeed also neat too
because it's faster (importent for data-encryption) in software then
AES (Rijandel).

twofish encrypts faster than aes-256 and slower than aes-128.
but I don't give a shit, whether it is faster, as long it is fast enough.

Post by Sebastian Rother
Or just a way to encrypt the disks where I could choose some parameters
of the algorithm (Bits, Rounds..)...

yeah, that is relly stupid. how to put your foot before your gun.

Post by Sebastian Rother
Bruce Schneier wouldn't develop an algorithm if he would still think
that Blowfish (an algorithm from 1993 and puplished 1994) would still
be the best choice for the next 10-30 years.

because he is bruce schneier? blowfish and twofish have partly different
applications, different considerations how to implement in hardware.
twofish was designed for aes, blowfish not. btw. bruce schneier never
said blowfish would be the best choice. as far as anybody knows, blowfish
is a strong cipher with nobody having an idea how to break it.


--knitti

[Andreas Bartelt]

Hi,

knitti wrote:
...

Post by knitti

Post by Sebastian Rother
At least if there some quant. computers 128Bit will not save ya day
anymore.

quantum computers are the real big buzzword to scare people into
irrational behaviour. nobody knows whether or when quantum computer
will be able to brute force 128 bit keys. and whether twofish will save you.

Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit
overall strength for a symmetric cipher. You can read it in 'applied
cryptography'. The reason for this recommendation is related to
collision attacks.

In my personal opinion, I think, the weakest link is entering the
password when opening a svnd device. Are there already solutions known
which combine passwords (knowledge) with hardware devices (i.e.
smartcards) or biometrics in order to access some secure storage? I
don't own one, but don't at least a couple of newer IBM notebook models
have a fingerprint reader and a TPM built in? Do you think a combination
of these measures would improve overall security?

regards,
Andreas

[Andreas Bartelt]

Andreas Bartelt wrote:
...

Post by Andreas Bartelt
Bruce Schneier recommends using 256 bit keys in order to achieve 128 bit
overall strength for a symmetric cipher. You can read it in 'applied
cryptography'. The reason for this recommendation is related to
collision attacks.

oops, typo. It's in the newer book 'practical cryptography'.

regards,
Andreas

[Tobias Ulmer]

Post by Sebastian Rother
Yes OpenBSD uses Blowfish and yes it si secure and YES it could be blf
with 448Bit. But OpenBSD uses (as far as I know) just 128Bit.

This is not true, vnconfig does read a maximum of 128 bytes (1024bit) and
the key can not be larger than that.
You can easily follow the function calls until it gets into blf_key().
blowfish(3) says that "The block size is 64 bits and the maximum key
size is 448 bits."

Post by Sebastian Rother
Blowfish is secure but Twofish is faster and as secure as Blowfish.
At least if there some quant. computers 128Bit will not save ya day
anymore.
The question is not "Is blowfish still secure enought".
It is more: Why can't the user choose how strong the data will get
encrypted?

menpower?

Post by Sebastian Rother
An ideal algorithm for user-accounts would be secure and slow as hell.
But then such an algorithm would just be usefull to protect the
user-passwords....
Blowfish is a good compromise but Twofish would be indeed also neat too
because it's faster (importent for data-encryption) in software then
AES (Rijandel).

I have Truecrypt on a windows box. The benchmarks of this app
show the blowfish ist faster than all the others on my computer.
As far as i can remember, it supports blowfish, twofish, aes and some
others. Have a look into it :)

Post by Sebastian Rother
A better solution to encrypt whole disks would be nice.
Maybe also using the AES-Engine from the VIA CPUs for this job.
Or just a way to encrypt the disks where I could choose some parameters
of the algorithm (Bits, Rounds..)...
FreeBSD has a nice way (geom) to encrypt whole disks (just from the
point of the usebility).
Kind regards,
Sebastian
p.s.
Bruce Schneier wouldn't develop an algorithm if he would still think
that Blowfish (an algorithm from 1993 and puplished 1994) would still
be the best choice for the next 10-30 years.

As far as i know here were certain design criterias (for example 128 bit
blocksize, hardware implementation and such stuff). And twofish does
not sound very much like a completly new thing to me?

Maybe someone should ask him why he did not say anything on his website
that blowfish is "insecure"? I mean, he also said that md5 und sha-1
are insecure, so why does he not do the same thing for blowfish?

Something else I would like to add. The real winner (in security) of
the NIST contest was serpent. Serpent can be implemented very well
in hardware, but does not perform good in software. The Linux
kernel has support for it and i used it some time, but it is really slow.
So if you are paranoid, don't cry for AES, go for serpent. There are
maybe reasons why the NSA didn't like it ;))


Another (ot) thing, it is easy to add keyfile(s) to vnconfig.
What you need is gpg and a small patch [1] that makes vnconfig read
from stdin. Encrypt your keyfile with gpg und put it on an usb stick.
Write some small shell scripts that pipe the output of gpg into
vnconfig and add some nice dialogs..

Now you can change your passphrase as often as you wish and
have your disk encrypted with a keyfile that is guarenteed not in
an lookup table at some supercomputers of some mysterious three
letter agency ;)

Tobias

[1] http://www.tmux.org/tmp/vnconfig.c.diff (That's my crappy
version of it, but there are other...)

[nikns]

http://www.onlamp.com/lpt/a/6384
Inside NetBSD's CGD
by Federico Biancuzzi
12/21/2005

OpenBSD didn't import CGD even if Ted Unangst wrote a port some time ago. Do you think
OpenBSD's svnd is already offering the same features?

RD: In a sense, OpenBSD's svnd appears to offer some of the same features as CGD. Before I
developed CGD, I examined svnd and determined that it has a number of deficiencies.

The biggest drawback of svnd is its lack of security in the general use case. It is vulnerable
to an offline dictionary attack. That is, you can generate a database mapping known ciphertext
blocks on the disk back into pass phrases that can be accessed in O(1) without even being in
possession of the disk. What's even worse is that the same database will work on any svnd disk.
It is possible--and perhaps even likely--that large agencies such as the NSA have constructed
such a database and can crack a majority of the svnds in the world in less than a second. The
way that one prevents an offline dictionary attack is to use a salt in conjunction with the pass
phrase, and this is what I did when I wrote CGD by using PKCS#5 PBKDF2. Offline dictionary
attacks have been well-known since at least the '70s, and salting the pass phrase has been
standard practice for over 30 years.