"Slower is more secure"
David Wagner
very careful with this type of reasoning. It is very easy to confuse
causation with correlation. The claim is at best a matter of correlation,
not causation.
Here's an analogy. A study examines how well kids do on a standardized
test (say, the SAT). It finds that one of the best predictive factors
for how well you do on the test is the following: "The larger your shoe
size, the better your test score". Do we then conclude that we ought
to buy feet stretchers to artificially elongate our feet so that we
will become smarter? Should we make a habit of periodically tugging
on our toes to work our way up to bigger shoes? Should we set out
to intentionally buy shoes that are one size too large to improve our
chances of getting into college?
Obviously the answer to all these questions is no. The very idea
is absurd. Do you see why? It has to do with the difference between
correlation and causation. In this case, it's not too hard to identify a
common cause: the older kids have larger shoe sizes, and have also learned
more, hence they do better on the test. In short, the correlation between
shoe size and test score is just that -- correlation, and nothing more.
There's no causation involved in either direction.
I hope this serves as a cautionary note that reminds you not to read
too much into the correlation between speed and insecurity in ciphers.
Michael Sierchio
> About the claim that "Slower ciphers tend to be more secure": Be
> very careful with this type of reasoning.
Ciphers which have expensive key schedules -- esp. those which are
not amenable to hardware acceleration -- would make brute force
key space searches more expensive, no?
Ursus Horibilis
"David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
news:ai3vu3$1l0g$2...@agate.berkeley.edu...
> About the claim that "Slower ciphers tend to be more secure": Be
> very careful with this type of reasoning. It is very easy to confuse
> causation with correlation. The claim is at best a matter of correlation,
> not causation.
>
I'm sure we'll hear from him shortly, but I believe Mr. Scott's hypothesis
is that "More secure ciphers tend to be slower, all other things being
equal."
[snip]
> There's no causation involved in either direction.
>
At this point, it would be more correct to say, "if there is a causal
relation, we can't identify it, and since we can't really measure the
'degree of secureness' anyway, we can't even prove there is a correlation,
let alone a causal relation."
> I hope this serves as a cautionary note that reminds you not to read
> too much into the correlation between speed and insecurity in ciphers.
I hope this serves to underscore the need for a credible "security" metric.
Until such is delivered and duly blessed, we're still going to be playing
with heuristics.
Mok-Kong Shen
Ursus Horibilis wrote:
>
> "David Wagner" <d...@mozart.cs.berkeley.edu> wrote:
> > About the claim that "Slower ciphers tend to be more secure": Be
> > very careful with this type of reasoning. It is very easy to confuse
> > causation with correlation. The claim is at best a matter of correlation,
> > not causation.
> >
>
> I'm sure we'll hear from him shortly, but I believe Mr. Scott's hypothesis
> is that "More secure ciphers tend to be slower, all other things being
> equal."
[snip]
I think that the condition 'all other things being equal'
is rather problematic. What does that exactly mean in
practice? Wouldn't a fairly 'deliberate' interpretation
of it unnecessarily or even improperly restrict the realm
where potential candidates could be compared? (cf. the
issue of comparing 'apples and oranges'.) For at the end
the user is only concerned with the security obtainable
and is indifferent to the types of design of the algorithms.
Imagine (contrary to reality) the hypothetical case where
one could rigorously measure the strength of ciphers and
where there exist a block cipher and a stream cipher that
are equally strong but their speeds are different. Could
we compare these or couldn't we do so because the
condition of 'all other things being equal' is seemingly
not fulfilled, e.g. the one has block size and rounds
while the other has nothing similar to these?
M. K. Shen
David Wagner
>Ciphers which have expensive key schedules -- esp. those which are
>not amenable to hardware acceleration -- would make brute force
>key space searches more expensive, no?
I addressed this claim earlier. If your favorite cipher has
a fast key schedule, there are straightforward ways to slow down
the key schedule to make exhaustive keysearch slower. See, e.g.,
John Kelsey, Bruce Schneier, Chris Hall, David
Wagner, "Secure Applications of Low-Entropy Keys",
http://www.counterpane.com/low-entropy.pdf
Udi Manber, "A Simple Scheme to Make Passwords
Based on One-Way Functions Much Harder to Crack",
http://citeseer.nj.nec.com/manber96simple.html
Martin Abadi, T. Mark A. Lomas, Roger Needham, "Strengthening
Passwords", http://citeseer.nj.nec.com/146623.html
That said, for most purposes it is a better idea to simply use
truly random secret keys. With any modern cipher, the key length
is large enough that exhaustive keysearch is then not a threat.
The conclusion is that a slow key schedule is not a very good
reason to prefer one cipher over another.
Edward Elliott
> I hope this serves to underscore the need for a credible "security" metric.
> Until such is delivered and duly blessed, we're still going to be playing
> with heuristics.
A hard metric would be nice, but is not really necessary (and may not be
possible). Lots of fields are forced to get by on heuristics, and do
just fine. Occasionally the heuristics may get shaken up a bit, but
that's part of life.
Edward Elliott
Ursus Horibilis
"Mok-Kong Shen" <mok-ko...@t-online.de> wrote in message
news:3D45922B...@t-online.de...
>
>
> Ursus Horibilis wrote:
> >
> > "David Wagner" <d...@mozart.cs.berkeley.edu> wrote:
>
> > > About the claim that "Slower ciphers tend to be more secure": Be
> > > very careful with this type of reasoning. It is very easy to confuse
> > > causation with correlation. The claim is at best a matter of
correlation,
> > > not causation.
> > >
> >
> > I'm sure we'll hear from him shortly, but I believe Mr. Scott's
hypothesis
> > is that "More secure ciphers tend to be slower, all other things being
> > equal."
> [snip]
>
> I think that the condition 'all other things being equal'
> is rather problematic.
Everything in this field is problematic; why would you expect this to be any
different?
> What does that exactly mean in
> practice? Wouldn't a fairly 'deliberate' interpretation
> of it unnecessarily or even improperly restrict the realm
> where potential candidates could be compared? (cf. the
> issue of comparing 'apples and oranges'.)
Posters to this newsgroup routinely mix apples and oranges, as it were,
without even the simple courtesy of acknowleging that they're making a fruit
salad when what was called-for was tomato juice. Thus, in the interests of
precision, one tries to restrict the ingredients to those necessary to do
the job.
> For at the end
> the user is only concerned with the security obtainable
> and is indifferent to the types of design of the algorithms.
Which user? Is the total responsibility for security to be borne by the
end-user? Have you no professional ethics?
> Imagine (contrary to reality)
Yes, there's a lot of that going on here, too. Let's stick with reality as
much as we can.
> the hypothetical case where
> one could rigorously measure the strength of ciphers and
> where there exist a block cipher and a stream cipher that
> are equally strong but their speeds are different.
I'll worry about that when you show me a credible metric for the strength of
either one.
> Could
> we compare these or couldn't we do so because the
> condition of 'all other things being equal' is seemingly
> not fulfilled, e.g. the one has block size and rounds
> while the other has nothing similar to these?
No problem. Either you told me that your hypothetical strength metric was
suitable for all types of ciphers, in which case the answer is, "Yes we
can", or you told me that it was not suitable for comparing ciphers of
different architectures, in which case I can't expect to use it for
comparisons between block and stream ciphers. Is that so inscrutable?
Mok-Kong Shen
Ursus Horibilis wrote:
>
> "Mok-Kong Shen" <mok-ko...@t-online.de> wrote:
> >
> > Ursus Horibilis wrote:
> > >
> > > "David Wagner" <d...@mozart.cs.berkeley.edu> wrote:
> >
> > > > About the claim that "Slower ciphers tend to be more secure": Be
> > > > very careful with this type of reasoning. It is very easy to confuse
> > > > causation with correlation. The claim is at best a matter of
> correlation,
> > > > not causation.
> > > >
> > >
> > > I'm sure we'll hear from him shortly, but I believe Mr. Scott's
> hypothesis
> > > is that "More secure ciphers tend to be slower, all other things being
> > > equal."
> > [snip]
> >
> > I think that the condition 'all other things being equal'
> > is rather problematic.
>
> Everything in this field is problematic; why would you expect this to be any
> different?
Maybe I should say that it is more problematic than
the average in my humble view.
>
> > What does that exactly mean in
> > practice? Wouldn't a fairly 'deliberate' interpretation
> > of it unnecessarily or even improperly restrict the realm
> > where potential candidates could be compared? (cf. the
> > issue of comparing 'apples and oranges'.)
>
> Posters to this newsgroup routinely mix apples and oranges, as it were,
> without even the simple courtesy of acknowleging that they're making a fruit
> salad when what was called-for was tomato juice. Thus, in the interests of
> precision, one tries to restrict the ingredients to those necessary to do
> the job.
O.k. let me ask a precise question: Is comparing a
block cipher with a stream cipher principally against
the rule of not comparing apples and oranges or not?
And please say why (in either case)?
>
> > For at the end
> > the user is only concerned with the security obtainable
> > and is indifferent to the types of design of the algorithms.
>
> Which user? Is the total responsibility for security to be borne by the
> end-user? Have you no professional ethics?
The user is the one whose information is to be protected
by a cipher, or more generally a security system. He is
the one that actually gets the benefit of crypto. What
has 'my professional ethic' to do here? Could you please
explain your point with some more details?
> > Imagine (contrary to reality)
>
> Yes, there's a lot of that going on here, too. Let's stick with reality as
> much as we can.
>
> > the hypothetical case where
> > one could rigorously measure the strength of ciphers and
> > where there exist a block cipher and a stream cipher that
> > are equally strong but their speeds are different.
>
> I'll worry about that when you show me a credible metric for the strength of
> either one.
I only construct a hypothetical scenario in order to
better (simpler) to illustrate the point in issue.
That is not uncommon in discussions, isn't it?
>
> > Could
> > we compare these or couldn't we do so because the
> > condition of 'all other things being equal' is seemingly
> > not fulfilled, e.g. the one has block size and rounds
> > while the other has nothing similar to these?
>
> No problem. Either you told me that your hypothetical strength metric was
> suitable for all types of ciphers, in which case the answer is, "Yes we
> can", or you told me that it was not suitable for comparing ciphers of
> different architectures, in which case I can't expect to use it for
> comparisons between block and stream ciphers. Is that so inscrutable?
Covered above in my view.
M. K. Shen
Paul Pires
David Wagner <d...@mozart.cs.berkeley.edu> wrote in message news:ai3vu3$1l0g$2...@agate.berkeley.edu...
A good example, but pretty subtle. It seems that there is some causation
seemimg stuff involved in cipher speed vrs security but it is a puny effect and
still really only a correlation. A slower cipher probably does more operations so
the breaking of it would require more labor. This is what proponents of Slow = good
fall back on as an example but it is a negeligible thing. It is linear isn't it? Make it twice
as slow and hacking it should be twice as slow. But, if a factor of 2 was important
for security, then you shouldn't be using such a nearly broken thing in the first place..
A factor of 2 could be usefull for speed and efficiency but cranking
DES from (Effort *2^56th) up to (2* Effort 2^56th) just does'nt sound
worthwile from a security standpoint and not a good trade off for the
speed lost.
Am I close?
Paul
Tom St Denis
Who says brute force is the best way? A slower cipher may have shortcut
attacks.
The point David was trying to make was that while good ciphers [e.g.
3DES and IDEA] seem to be secure [in conventional cryptosystems,
yadadada] the fact that they are compariatively slower [then say AES or
RC5, etc...] is not a causation. E.g. 3DES being slower doesn't make it
more secure then DES.
So while your key schedule may take 7 years to complete if you have
trivial flaws [say all linear] it would probably not take long to attack it.
Tom
Tom St Denis
> "David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
> news:ai3vu3$1l0g$2...@agate.berkeley.edu...
>
>>About the claim that "Slower ciphers tend to be more secure": Be
>>very careful with this type of reasoning. It is very easy to confuse
>>causation with correlation. The claim is at best a matter of correlation,
>>not causation.
>>
>
>
> I'm sure we'll hear from him shortly, but I believe Mr. Scott's hypothesis
> is that "More secure ciphers tend to be slower, all other things being
> equal."
So he is arguing that all ciphers should be slow? I don't get this?
the point of "state of the art" is to advance things. E.g. faster ciphers.
>>There's no causation involved in either direction.
>>
>
>
> At this point, it would be more correct to say, "if there is a causal
> relation, we can't identify it, and since we can't really measure the
> 'degree of secureness' anyway, we can't even prove there is a correlation,
> let alone a causal relation."
No I think David [Wagner] hit it on the button. Look at say Serpent and
compare it to 3DES. Serpent is faster than 3DES and AFATK [they] more
secure.
What Wagner was trying to say is that being slow doesn't cause a cipher
to be secure. It just happens that secure ciphers and slow ciphers then
to correlate. Its an observation not a law [since the 3des/serpent
observation violates original observation].
>>I hope this serves as a cautionary note that reminds you not to read
>>too much into the correlation between speed and insecurity in ciphers.
>
>
> I hope this serves to underscore the need for a credible "security" metric.
> Until such is delivered and duly blessed, we're still going to be playing
> with heuristics.
Which is already done. Why do you think cipher designs quote their
DC/LC bounds, the effectiveness of other attacks [e.g. interpolation,
saturation, truncated differentials], etc...
Its hard to concretely prove anything specially in realms where attacks
get complicated severely [consider linear hulls] but you can take the
set of basic known attacks and say "I resist these XYZ much".
That is about as much metric as far as security is concerned. Of course
size, speed and complexity are big factors.
Tom
Ursus Horibilis
"Tom St Denis" <tomst...@yahoo.com> wrote in message
news:3d45a...@news.teranews.com...
[snip[
> Who says brute force is the best way? A slower cipher may have shortcut
> attacks.
>
> The point David was trying to make was that while good ciphers [e.g.
> 3DES and IDEA] seem to be secure [in conventional cryptosystems,
> yadadada] the fact that they are compariatively slower [then say AES or
> RC5, etc...] is not a causation. E.g. 3DES being slower doesn't make it
> more secure then DES.
>
This is a bad choice for a counter-example because, while being slower
doesn't make 3DES more secure than DES, other things being equal, the
processing that we believe gives 3DES more security does make 3DES slower
than DES. Thus, your example appears to support Mr. Scott's hypothesis.
Tom St Denis
Not really. What makes 3DES more secure from a practical standpoint is
the longer key. Give DES a full (48*16)-bit key and it not only resist
DC and LC more but will resist the obvious brute force.
People just did 3DES over longkey-DES because they are a) stupid and b)
want to build with existing DES hardware... Only problem is 20 years
later people are still using 3DES despite the ample time to make a chip
which just loads bigger keys...
Tom
Paul Pires
Ursus Horibilis <ursus_h...@hotmail.com> wrote in message
news:1Lf19.44021$ND5.4...@e3500-atl2.usenetserver.com...
>
> "David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
> news:ai3vu3$1l0g$2...@agate.berkeley.edu...
> > About the claim that "Slower ciphers tend to be more secure": Be
> > very careful with this type of reasoning. It is very easy to confuse
> > causation with correlation. The claim is at best a matter of correlation,
> > not causation.
> >
>
> I'm sure we'll hear from him shortly, but I believe Mr. Scott's hypothesis
> is that "More secure ciphers tend to be slower, all other things being
> equal."
>
>
> [snip]
>
> > There's no causation involved in either direction.
> >
>
> At this point, it would be more correct to say, "if there is a causal
> relation, we can't identify it, and since we can't really measure the
> 'degree of secureness' anyway, we can't even prove there is a correlation,
> let alone a causal relation."
Too complicated. First you see if the postulated correlation or causation
is likely to be significant enough for the effort involved in exactly quantifying
it. If it hurts when you do that...don't do that. Is there ANY examples that
complicating a cipher (in general) results in increasing the effort to break it
with any leverage?
Everything I've seen is general claims that follow the common sense
approach of "Twice as much effort to encrypt has to cost an attacker
twice as much effort to crack. So what? Is chasing a 2x security margin
worth any effort at all? I could see it if it made it 2^32rd times better
but who wants an algorithm that is 2^32nd times slower?
That is like wearing suspenders, a belt, a life vest, pressure suit and
a parachute. Might be appropriate in some strange applications
but it is generally foolish.
I guess I just don't understand this whole thread.
>
> > I hope this serves as a cautionary note that reminds you not to read
> > too much into the correlation between speed and insecurity in ciphers.
>
> I hope this serves to underscore the need for a credible "security" metric.
> Until such is delivered and duly blessed, we're still going to be playing
> with heuristics.
Only if it makes sense to do so.
Paul
>
>
>
>
Mok-Kong Shen
Ursus Horibilis wrote:
>
> "Tom St Denis" <tomst...@yahoo.com> wrote:
> [snip[
> > Who says brute force is the best way? A slower cipher may have shortcut
> > attacks.
> >
> > The point David was trying to make was that while good ciphers [e.g.
> > 3DES and IDEA] seem to be secure [in conventional cryptosystems,
> > yadadada] the fact that they are compariatively slower [then say AES or
> > RC5, etc...] is not a causation. E.g. 3DES being slower doesn't make it
> > more secure then DES.
> >
>
> This is a bad choice for a counter-example because, while being slower
> doesn't make 3DES more secure than DES, other things being equal, the
> processing that we believe gives 3DES more security does make 3DES slower
> than DES. Thus, your example appears to support Mr. Scott's hypothesis.
I suppose that Tom St Denis had an apparent typo. The
phrase 'more secure than DES' should read 'more secure
than AES', I guess.
M. K. Shen
Mok-Kong Shen
Tom St Denis wrote:
>
> Ursus Horibilis wrote:
Minutes ago I posted my conjecture of there being a
typo of yours. Sorry that I am wrong.
M. K. Shen
Ursus Horibilis
"Tom St Denis" <tomst...@yahoo.com> wrote in message
news:3d45a...@news.teranews.com...
> Ursus Horibilis wrote:
> > "David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
> > news:ai3vu3$1l0g$2...@agate.berkeley.edu...
> >
> >>About the claim that "Slower ciphers tend to be more secure": Be
> >>very careful with this type of reasoning. It is very easy to confuse
> >>causation with correlation. The claim is at best a matter of
correlation,
> >>not causation.
> >>
> >
> >
> > I'm sure we'll hear from him shortly, but I believe Mr. Scott's
hypothesis
> > is that "More secure ciphers tend to be slower, all other things being
> > equal."
>
> So he is arguing that all ciphers should be slow? I don't get this?
> the point of "state of the art" is to advance things. E.g. faster
ciphers.
>
I'll have to let him speak for himself about that. What I understood him to
say was that, in general, secure ciphers *are* slow. I take that as his
observervation based on his experience or his perception of reality. I do
not see that he is implying that slow ciphers are secure. Perhaps I didn't
read carefully enough.
> >>There's no causation involved in either direction.
> >>
> >
> >
> > At this point, it would be more correct to say, "if there is a causal
> > relation, we can't identify it, and since we can't really measure the
> > 'degree of secureness' anyway, we can't even prove there is a
correlation,
> > let alone a causal relation."
>
> No I think David [Wagner] hit it on the button. Look at say Serpent and
> compare it to 3DES. Serpent is faster than 3DES and AFATK [they] more
> secure.
>
> What Wagner was trying to say is that being slow doesn't cause a cipher
> to be secure. It just happens that secure ciphers and slow ciphers then
> to correlate. Its an observation not a law [since the 3des/serpent
> observation violates original observation].
Well, speaking literally here, if you can't measure it accurately, you can't
correlate it except in the somewhat fuzzy sense performed by neural network
packages. I don't see any data demonstrating correlation or lack thereof
either way. All I see is assertions that there would be correlations, if
only we could show them.
>
> >>I hope this serves as a cautionary note that reminds you not to read
> >>too much into the correlation between speed and insecurity in ciphers.
> >
> >
> > I hope this serves to underscore the need for a credible "security"
metric.
> > Until such is delivered and duly blessed, we're still going to be
playing
> > with heuristics.
>
> Which is already done. Why do you think cipher designs quote their
> DC/LC bounds, the effectiveness of other attacks [e.g. interpolation,
> saturation, truncated differentials], etc...
>
All of which we hope are relevant to the problem at hand. And, in the sense
of automated code breaking, they may very well be highly relevant. Proving
it is, as yet, an unsolved problem.
Tom St Denis
No, no no no no!
You guys are mising Wagners point [which IMHO makes perfect sense to me].
The fact that 3DES is slower doesn't make it more secure. The primary
CAUSATION of making it more secure is the ***longer key size***.
So take normal DES and change the key schedule to accept say 256-bit
keys. Provided the key schedule is sound you will have a cipher OF THE
SAME SPEED that is more secure than regular DES [against, in this case,
brute force attacks].
So as Wagner pointed out, the fact that you can correlated "3DES slower"
and "3DES stronger" doesn't mean slower => stronger.
The whole point of Wagners post was to show that just because two things
are correlated doesn't mean one caused the other.
So just because you have a slow cipher in hand doesn't mean its secure.
Tom
Tom St Denis
Oops... I replied to that... hehehe ignore that. ;-)
Tom
Tom St Denis
> "Tom St Denis" <tomst...@yahoo.com> wrote in message
> news:3d45a...@news.teranews.com...
>
>>Ursus Horibilis wrote:
>>
>>>"David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
>>>news:ai3vu3$1l0g$2...@agate.berkeley.edu...
>>>
>>>
>>>>About the claim that "Slower ciphers tend to be more secure": Be
>>>>very careful with this type of reasoning. It is very easy to confuse
>>>>causation with correlation. The claim is at best a matter of
>>>
> correlation,
>
>>>>not causation.
>>>>
>>>
>>>
>>>I'm sure we'll hear from him shortly, but I believe Mr. Scott's
>>
> hypothesis
>
>>>is that "More secure ciphers tend to be slower, all other things being
>>>equal."
>>
>>So he is arguing that all ciphers should be slow? I don't get this?
>>the point of "state of the art" is to advance things. E.g. faster
>
> ciphers.
>
>
> I'll have to let him speak for himself about that. What I understood him to
> say was that, in general, secure ciphers *are* slow. I take that as his
> observervation based on his experience or his perception of reality. I do
> not see that he is implying that slow ciphers are secure. Perhaps I didn't
> read carefully enough.
I don't see the connection though. I mean being slow could be a result
of poorly chosen ops, or too many rounds, or too big data structures or
etc...
>>>>There's no causation involved in either direction.
>>>>
>>>
>>>
>>>At this point, it would be more correct to say, "if there is a causal
>>>relation, we can't identify it, and since we can't really measure the
>>>'degree of secureness' anyway, we can't even prove there is a
>>
> correlation,
>
>>>let alone a causal relation."
>>
>>No I think David [Wagner] hit it on the button. Look at say Serpent and
>>compare it to 3DES. Serpent is faster than 3DES and AFATK [they] more
>>secure.
>>
>>What Wagner was trying to say is that being slow doesn't cause a cipher
>>to be secure. It just happens that secure ciphers and slow ciphers then
>>to correlate. Its an observation not a law [since the 3des/serpent
>>observation violates original observation].
>
>
> Well, speaking literally here, if you can't measure it accurately, you can't
> correlate it except in the somewhat fuzzy sense performed by neural network
> packages. I don't see any data demonstrating correlation or lack thereof
> either way. All I see is assertions that there would be correlations, if
> only we could show them.
I was trying to show that the "observation" at hand doesn't always hold
empiracaly [sp?].
>>>>I hope this serves as a cautionary note that reminds you not to read
>>>>too much into the correlation between speed and insecurity in ciphers.
>>>
>>>
>>>I hope this serves to underscore the need for a credible "security"
>>
> metric.
>
>>>Until such is delivered and duly blessed, we're still going to be
>>
> playing
>
>>>with heuristics.
>>
>>Which is already done. Why do you think cipher designs quote their
>>DC/LC bounds, the effectiveness of other attacks [e.g. interpolation,
>>saturation, truncated differentials], etc...
>>
>
>
> All of which we hope are relevant to the problem at hand. And, in the sense
> of automated code breaking, they may very well be highly relevant. Proving
> it is, as yet, an unsolved problem.
Well you can prove some attacks won't work with just some high school math.
Tom
Daniel Mehkeri
It does? 3DES is 3 times slower than DES to encrypt/decrypt, and 2^56
times slower to brute force. DES+SlowInputMangling is N times slower than
DES to encrypt/decrypt, and N times slower to brute force. I suppose
you're going to tell me that DES/3DES is somehow "other things being
equal" but DES+SlowInputMangling is somehow "other things not equal" but
I'll let you make that argument.
--
To email me, remove my head.
Paul Pires
Tom St Denis <tomst...@yahoo.com> wrote in message news:3d45a79a$1...@news.teranews.com...
> Ursus Horibilis wrote:
> > "Tom St Denis" <tomst...@yahoo.com> wrote in message
> > news:3d45a...@news.teranews.com...
> >
> > [snip[
> >
> >>Who says brute force is the best way? A slower cipher may have shortcut
> >>attacks.
> >>
> >>The point David was trying to make was that while good ciphers [e.g.
> >>3DES and IDEA] seem to be secure [in conventional cryptosystems,
> >>yadadada] the fact that they are compariatively slower [then say AES or
> >>RC5, etc...] is not a causation. E.g. 3DES being slower doesn't make it
> >>more secure then DES.
> >>
> >
> >
> > This is a bad choice for a counter-example because, while being slower
> > doesn't make 3DES more secure than DES, other things being equal, the
> > processing that we believe gives 3DES more security does make 3DES slower
> > than DES. Thus, your example appears to support Mr. Scott's hypothesis.
The "More processing" involved was done for the specific reason of properly utilizing
a bigger key with minimal change to the archetecture, not for the purpose of making it
slower. It is more secure because the desired outcome of the modification was achieved
(or so it seems),but not because it developed magical slowness.
Cause, effect and coincidence.
>
> Not really. What makes 3DES more secure from a practical standpoint is
> the longer key. Give DES a full (48*16)-bit key and it not only resist
> DC and LC more but will resist the obvious brute force.
>
> People just did 3DES over longkey-DES because they are a) stupid and b)
> want to build with existing DES hardware... Only problem is 20 years
> later people are still using 3DES despite the ample time to make a chip
> which just loads bigger keys...
Ehrr... If it can use a bigger key, it's not DES just like 3DES is a completely
different algorithm than DES. It may be related in lineage and name but it is
not "The same but bigger" to me. How could you make DES use a bigger
key without having a bigger block size or more and different round operations?
By this logic AES is longkey DES. Pretty much the same (A block cipher),
with a related name but modernized. It fixed the small key problem and a
couple of other tweeks while we were at it :-) AND by the way... It got
faster, not slower.
Paul
>
> Tom
>
>
Ursus Horibilis
"Tom St Denis" <tomst...@yahoo.com> wrote in message
news:3d45a...@news.teranews.com...
Heh, heh, heh! We're arguing two completely different issues. I haven't
seen anything in this thread that takes issue with Wagner's point that
"slower is not necessarily more secure". Anyone with a grain of reasoning
ability can pretty well agree with that statement.
My first point is that I don't think that Scott was arguing that "slower is
more secure". My second point is that common sense tells you that there
must be some truth to the view that "more secure is often slower." You've
made the point twice now, first by agreeing that 3DES is both slower and
more secure than DES and second, by implying that a DES-like cipher could be
made more secure by expanding the key size and the number of rounds. Now,
tell me, don't you expect this more secure version of DES to be slower than
"real" DES just because of having to do more processing on more bits?
> So take normal DES and change the key schedule to accept say 256-bit
> keys. Provided the key schedule is sound you will have a cipher OF THE
> SAME SPEED that is more secure than regular DES [against, in this case,
> brute force attacks].
>
How do you believe that "DES on steroids" is going to run at the same speed
as "normal DES". Are you talking about blocks per second, bytes per second
or what? Do you have any supporting evidence. And what evidence do you
have that inflating DES gives you a more secure cipher?
Tom St Denis
> How do you believe that "DES on steroids" is going to run at the same speed
> as "normal DES". Are you talking about blocks per second, bytes per second
> or what? Do you have any supporting evidence. And what evidence do you
> have that inflating DES gives you a more secure cipher?
First, yes it would be the same speed in software at least.
Conceptually its the same process just that that 48-bit round keys are
not derived from a key scheduler from a 56-bit key. So in practice it
should be no slower.
Supporting evidence of security? See Bihams papers on "Differential
Cryptanalysis on Full 16-round DES" [or something like that]. Basically
he states that DC takes 2^61 effort IIRC which is higher then the
current attacks [IIRC 2^47 work....]
Tom
Daniel Mehkeri
>
> My first point is that I don't think that Scott was arguing that "slower is
> more secure". My second point is that common sense tells you that there
> must be some truth to the view that "more secure is often slower." You've
> made the point twice now, first by agreeing that 3DES is both slower and
> more secure than DES and second, by implying that a DES-like cipher could be
> made more secure by expanding the key size and the number of rounds. Now,
> tell me, don't you expect this more secure version of DES to be slower than
> "real" DES just because of having to do more processing on more bits?
>
There's a world of difference between "more secure is sometimes slower"
and "slower is more secure because it takes longer to brute force".
David Wagner
>This is a bad choice for a counter-example [...]
Maybe you'll like this better. Consider the following three algorithms:
plain DES: E_k(x) = DES(k,x)
DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
no more secure than plain DES.
David Wagner
>My first point is that I don't think that Scott was arguing that "slower is
>more secure".
Ok.
>My second point is that common sense tells you that there
>must be some truth to the view that "more secure is often slower."
I certainly agree with you there. That's hard to argue with.
Gregory G Rose
Tom St Denis <tomst...@yahoo.com> wrote:
>Not really. What makes 3DES more secure from a practical standpoint is
>the longer key. Give DES a full (48*16)-bit key and it not only resist
>DC and LC more but will resist the obvious brute force.
Que? This is not true, and was one of the big
surprises to come out of B&H's rediscovery of
Differential Cryptanalysis. It really torpedoed
all the people who'd been saying that the key
length had been artificially shortened. In fact,
it was about the longest key that made any
difference to DC.
I'm not so certain about this one, but I believe
that the 768-bit key is actually *weaker* than the
56-bit one, because you don't have to worry about
the dependency of key bits in early and late
rounds.
>People just did 3DES over longkey-DES because they are a) stupid and b)
>want to build with existing DES hardware... Only problem is 20 years
>later people are still using 3DES despite the ample time to make a chip
>which just loads bigger keys...
Not at all. Where did you get this crazy notion?
Greg.
--
Greg Rose INTERNET: g...@qualcomm.com
Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199
Level 3, 230 Victoria Road, http://people.qualcomm.com/ggr/
Gladesville NSW 2111 232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C
David Wagner
keys) can be done with 2^47 chosen plaintexts. I've seen a rough
estimate of 2^60 chosen plaintexts to break DES with independent round
subkeys (768-bit keys). However, the 2^47 attack has been extremely
well optimized, whereas the 2^60 attack is unoptimized. In any case,
the difference between the two is more or less negligible.
Yes, I believe the available evidence supports the claim that DES's
key size accurately represents the complexity of the best known attack
(if we assume 1 chosen-plaintext = 1 trial decryption).
Also, I'd feel much safer with 3DES than with DES with independent
round subkeys.
SCOTT19U.ZIP_GUY
<1Lf19.44021$ND5.4...@e3500-atl2.usenetserver.com>:
>
>"David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
>news:ai3vu3$1l0g$2...@agate.berkeley.edu...
>> About the claim that "Slower ciphers tend to be more secure": Be
>> very careful with this type of reasoning. It is very easy to confuse
>> causation with correlation. The claim is at best a matter of
>> correlation, not causation.
>>
>
>I'm sure we'll hear from him shortly, but I believe Mr. Scott's
>hypothesis is that "More secure ciphers tend to be slower, all other
>things being equal."
>
Yes.
>
>[snip]
>
>> There's no causation involved in either direction.
>>
>
>At this point, it would be more correct to say, "if there is a causal
>relation, we can't identify it, and since we can't really measure the
>'degree of secureness' anyway, we can't even prove there is a
>correlation, let alone a causal relation."
>
>> I hope this serves as a cautionary note that reminds you not to read
>> too much into the correlation between speed and insecurity in ciphers.
>
>I hope this serves to underscore the need for a credible "security"
>metric. Until such is delivered and duly blessed, we're still going to
>be playing with heuristics.
>
I think with the advent of quantum computers. We will develop
better measures of what secutrity really is. Till then its a black
art. And one of the few bright spots is Shananon. We will playing
with heuristics for a long time.
David A. Scott
--
My Crypto code
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott19.zip
http://cryptography.org/cgi-bin/crypto.cgi/Misc/scott16.zip
http://www.jim.com/jamesd/Kong/scott19u.zip old version
My Compression code http://bijective.dogma.net/
**TO EMAIL ME drop the roman "five" **
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged.
As a famous person once said "any cryptograhic
system is only as strong as its weakest link"
jsa...@ecn.ab.ca
: About the claim that "Slower ciphers tend to be more secure": Be
: very careful with this type of reasoning. It is very easy to confuse
: causation with correlation. The claim is at best a matter of correlation,
: not causation.
Absolutely. With one exception, of course. The Blowfish key schedule.
There, it's causation.
John Savard
SCOTT19U.ZIP_GUY
>
>I'll have to let him speak for himself about that. What I understood
>him to say was that, in general, secure ciphers *are* slow. I take that
>as his observervation based on his experience or his perception of
>reality. I do not see that he is implying that slow ciphers are secure.
> Perhaps I didn't read carefully enough.
>
I think you read it clear enough. It wasn't meant to be axomatic.
It was just that the goal in AES and such it to design for pure
speed and that means that you cut corners and don't really design
for the unknown. True they do there best to limit the known attacks
but the very fact of doing less makes them weak to the unknown attacks.
Yet to be discovered.
Don't get me wrong its nice to have fast ciphers. But one should
also have ciphers where security counts for much more than speed.
Unfortunately as pointed out by many there is no real measure for
security but time is easy to measure. So as a result of being easy
to measure it seems it gets more than the lion sure of the focus in the
making of new ciphers.
I think that chaining of ciphers (though papers show that sometimes
the strength is not stronger than first cipher) is one valid why of
making a stronger system. Especailly if the designs use different desing
theorys.
Richard Parker
> Not really. What makes 3DES more secure from a practical standpoint is
> the longer key. Give DES a full (48*16)-bit key and it not only resist
> DC and LC more but will resist the obvious brute force.
>
> People just did 3DES over longkey-DES because they are a) stupid and b)
> want to build with existing DES hardware... Only problem is 20 years
> later people are still using 3DES despite the ample time to make a chip
> which just loads bigger keys...
I think there could be other reasons that DES with independent round subkeys
(your 768-bit longkey-DES) was not adopted as a replacement for DES. For
example, the absence of a key schedule might also have been a concern.
Consider the popular Davies-Meyer hash construction, the lack of key
schedule makes DES with independent subkeys a very poor choice of a block
cipher primitive for this construction.
I also recall that DES with independent subkeys can be broken with one
related key and approximately 2^16 chosen plaintexts (or 15 related keys and
60 chosen plaintexts). Of course as a composition cipher 3DES itself is not
immune to related key attack, but it is more resistant than DES with
independent subkeys. Admittedly when just used as a cipher DES with
independent subkey is unlikely to be vulnerable to such attacks due to
largely impractical nature of related-key attacks.
-Richard
SCOTT19U.ZIP_GUY
<Pine.GSO.4.44.020729...@victoria.swi.com>:
Mr Ursus stats my postion far better than you. First of all
no one does brute force as a solution. People only talk about
how long it takes to brute force a solution since they know its
not possible on current machines till the sun burns out. So
stop the nonsense with the brute force search issue. Except for
really short key ciphers
Another way to look at is suspose GOD was designing a cipher
and decided it was going to use say 128 bit block size 256 bit
key and run at some fixed speed on a 486 machine. And this god
has the power to tell how hard it is to break if Satan gets
the ciphertext. Now if the speed requirement is real fast Gods
program can't do much, Add XOR the key and write it out. Satan
breaks this quick. As GOD allows more opertaions and the perfect
program is written for the time allowed. Its going to be able to do more
and it gets more secure. It surly a fuction of how much time Gods say that
it allows the encryption to run. The questios are these. Is there a time
where maximum security occurs or is it ever reached. Secondly is
the real security actually that great. Maybe the true security of
any such system is actully very low we just don't know the easy
ways to crack this in a black box apporach. God may say hay you
idiots treat the whole message as a single block.
SCOTT19U.ZIP_GUY
>
>I'm not so certain about this one, but I believe
>that the 768-bit key is actually *weaker* than the
>56-bit one, because you don't have to worry about
>the dependency of key bits in early and late
>rounds.
>
>
How could this be. There has to be some assumptions
of how the keys picked since one could if one wished
pick the 768 bit key in such a way that it matches the
56 bit key. So it can't be weaker since one is a subset
of the other. There has to be more than what your saying.
I belive it may be close but not welling to belive its going to
be weaker.
jsa...@ecn.ab.ca
: No, no no no no!
: You guys are mising Wagners point [which IMHO makes perfect sense to me].
: The fact that 3DES is slower doesn't make it more secure. The primary
: CAUSATION of making it more secure is the ***longer key size***.
On the other hand, 8-round DES with a 56-bit key is extremely insecure.
David Wagner's point is that the fact that a _completely different_ cipher
is slower than another cipher doesn't make it more secure; the slower
cipher might have been designed by someone who doesn't know as much about
cryptography than the person who designed the faster one.
I _think_ that Quadibloc 2002 is more secure than Rijndael, but that may
be because I have an inflated idea of my own competence. It might actually
be less secure. The fact that it is a lot slower than Rijndael certainly
is no guarantee that it is more secure.
For a given key size, and a given cipher design, adding more rounds
increases security until no attack is better than brute force, and then
more rounds don't give you anything. The number of rounds needed depends
on the design, and some designs may be hopelessly bad.
John Savard
Edward Elliott
> g...@qualcomm.com (Gregory G Rose) wrote in <ai4lef$k...@qualcomm.com>:
>
>>I'm not so certain about this one, but I believe
>>that the 768-bit key is actually *weaker* than the
>>56-bit one, because you don't have to worry about
>
> of how the keys picked since one could if one wished
> pick the 768 bit key in such a way that it matches the
> 56 bit key. So it can't be weaker since one is a subset
The subset of 768-bit keys which match a 56-bit key is infinitesimally
small by comparison. It is possible for the other 768-bit keys to be
weaker than 56-bit keys, making the entire set of 768-bit keys weaker
_on average_.
However I find even this claim to be dubious. It seems intuitively that
768-bit keys must be more work, even if only a little. I believe Wagner
confirmed as much earlier, though the work increase is surprisingly
small (2^60 total IIRC).
Edward Elliott
Gregory G Rose
SCOTT19U.ZIP_GUY <david_...@emailv.com> wrote:
<g...@qualcomm.com (Gregory G Rose) wrote in <ai4lef$k...@qualcomm.com>:
<
<>
<>I'm not so certain about this one, but I believe
<>that the 768-bit key is actually *weaker* than the
<>56-bit one, because you don't have to worry about
<>the dependency of key bits in early and late
<>rounds.
<>
<>
<
< How could this be. There has to be some assumptions
<of how the keys picked since one could if one wished
<pick the 768 bit key in such a way that it matches the
<56 bit key. So it can't be weaker since one is a subset
<of the other. There has to be more than what your saying.
<I belive it may be close but not welling to belive its going to
<be weaker.
You're right, I should take my foot out of my
mouth. I went and looked it up, and independent
subkeys are slightly stronger (but not much).
There is a cipher that was proposed for cellular
telephony applications (but never, thankfully,
adopted) where independent subkeys were
noticeably weaker than key-scheduled keys (but of
course it was a broken cipher...). Perhaps that
was the one I was thinking of.
David Wagner
>It was just that the goal in AES and such it to design for pure
>speed and that means that you cut corners and don't really design
>for the unknown. True they do there best to limit the known attacks
>but the very fact of doing less makes them weak to the unknown attacks.
>Yet to be discovered.
>
> Don't get me wrong its nice to have fast ciphers. But one should
>also have ciphers where security counts for much more than speed.
>Unfortunately as pointed out by many there is no real measure for
>security but time is easy to measure. So as a result of being easy
>to measure it seems it gets more than the lion sure of the focus in the
>making of new ciphers.
I agree.
I guess that there are some alternatives for those worried about the
security of AES. One natural possibility might be Triple AES (hey,
why not?).
Mok-Kong Shen
Richard Parker wrote:
>
> I think there could be other reasons that DES with independent round subkeys
> (your 768-bit longkey-DES) was not adopted as a replacement for DES. For
> example, the absence of a key schedule might also have been a concern.
> Consider the popular Davies-Meyer hash construction, the lack of key
> schedule makes DES with independent subkeys a very poor choice of a block
> cipher primitive for this construction.
>
> I also recall that DES with independent subkeys can be broken with one
> related key and approximately 2^16 chosen plaintexts (or 15 related keys and
> 60 chosen plaintexts). Of course as a composition cipher 3DES itself is not
> immune to related key attack, but it is more resistant than DES with
> independent subkeys. Admittedly when just used as a cipher DES with
> independent subkey is unlikely to be vulnerable to such attacks due to
> largely impractical nature of related-key attacks.
A question of ignorance: What could be the basic
reasons (causes of general fundamental nature) that
independent round keys render a poorer result
than dependent round keys (all derived from a
single key)? Thanks.
M. K. Shen
Mok-Kong Shen
David Wagner wrote:
>
[snip]
> I guess that there are some alternatives for those worried about the
> security of AES. One natural possibility might be Triple AES (hey,
> why not?).
Since AES is fast enough, I would say that 3AES should
be the 'standard' solution (for general usage in the
public) in case one has concerns about eventual
insufficiency of protection by AES alone.
M. K. Shen
Richard Parker
>> I also recall that DES with independent subkeys can be broken with one
>> related key and approximately 2^16 chosen plaintexts (or 15 related keys and
>> 60 chosen plaintexts). Of course as a composition cipher 3DES itself is not
>> immune to related key attack, but it is more resistant than DES with
>> independent subkeys. Admittedly when just used as a cipher DES with
>> independent subkey is unlikely to be vulnerable to such attacks due to
>> largely impractical nature of related-key attacks.
>
> A question of ignorance: What could be the basic
> reasons (causes of general fundamental nature) that
> independent round keys render a poorer result
> than dependent round keys (all derived from a
> single key)? Thanks.
Are you referring to related key attacks on 3DES and on DES with independent
round subkeys? If so, you are laboring under a misconception, in that case
one can be considered to be comparing two different ciphers each using
independent round keys, not the same cipher with and without dependent round
keys.
A comparison of related key attacks on 3DES and on DES with independent
round subkeys is essentially a comparison of a 3-round cipher with
independent 56-bit round subkeys to a 16-round cipher with 48-bit round
subkeys. Note that when treating 3DES as a 3-round cipher, a single "round"
in 3DES is much stronger than a round in DES - and in "Related-Key
Cryptanalysis of 3-WAY, Biham-DES, CAST, DES-X, NewDES, RC2, and TEA" by
Kelsey, Schneier and Wagner they say the following: "In general, when
independent round subkeys are in use, the strength of a cipher against
related-key attacks will be approximately proportional to the strength of
one round standing on its own."
-Richard
Mok-Kong Shen
Richard Parker wrote:
>
> Mok-Kong Shen wrote:
......
[snip]
> Are you referring to related key attacks on 3DES and on DES with independent
> round subkeys?
Sorry for unclearness of my question and my poor
knowledge. I meant that, for a given block cipher,
independent round keys should in general be better
than (dependent) round keys generated from a key
schedule (from a single key). (I suppose 'independent
keys' exclude any issue of 'related keys'. Is that
right?)
M. K. Shen
Richard Parker
> What could be the basic reasons (causes of general fundamental nature)
> that independent round keys render a poorer result than dependent round
> keys (all derived from a single key)?
Mok-Kong Shen wrote on 7/30/02 12:25 AM:
> I meant that, for a given block cipher, independent round keys should
> in general be better than (dependent) round keys generated from a key
> schedule (from a single key).
Now I am confused. Those two statements sound to me like opposing points of
view.
In any case, I don't think either hypothesis is necessarily correct. While
a key schedule (and thus dependent round subkeys) is typically a desirable
feature for block cipher, I can think of several "pathological" key
schedules that would make a block cipher worse than a variant that omitted
the key schedule (i.e. one with independent round subkeys).
> (I suppose 'independent keys' exclude any issue of 'related keys'. Is that
> right?)
No. I would expect a block cipher with independent round subkeys to be
vulnerable to related-key attacks.
-Richard
jsa...@ecn.ab.ca
: SCOTT19U.ZIP_GUY wrote:
: >It was just that the goal in AES and such it to design for pure
: >speed and that means that you cut corners and don't really design
: >for the unknown. True they do there best to limit the known attacks
: >but the very fact of doing less makes them weak to the unknown attacks.
: >Yet to be discovered.
: > Don't get me wrong its nice to have fast ciphers. But one should
: >also have ciphers where security counts for much more than speed.
: >Unfortunately as pointed out by many there is no real measure for
: >security but time is easy to measure. So as a result of being easy
: >to measure it seems it gets more than the lion sure of the focus in the
: >making of new ciphers.
: I agree.
I'm glad of that. Since you agree, it's safe for me to admit that I agree
as well; intense emphasis on speed does create the potential for security
limitations.
: I guess that there are some alternatives for those worried about the
: security of AES. One natural possibility might be Triple AES (hey,
: why not?).
That is a natural possibility, and it has the advantage that it involves a
cipher that has been well-studied and one that will be easily available in
hardware chips and the like. Of course, if one's fear is that the emphasis
on speed has led to the possibility of a near-fatal flaw against some
unknown attack, one might want something really different.
But something "really different" from a less recognized source runs the
risk of having a bad weakness against even a known attack. There's a
reason some people are regarded as the experts in cryptography. One way to
address this is what Terry Ritter had been suggesting: use a mixture of
different ciphers.
John Savard
Simon Johnson
>
> I guess that there are some alternatives for those worried about the
> security of AES. One natural possibility might be Triple AES (hey,
> why not?).
hehe, How about increasing the number of round of DES from 16 to 21 (i
think at this point no known attack can defeat it faster than
brute-force) and then remove the key-shedule and use independant
subkeys - unless you want to design a better key shedule with a
smaller key.
The only known way to break this cipher would be a known plain-text
attack using 2^64 blocks. I think this is adequate. Exhaustive key
search would be practically impossible. DES has been around for many
many years.. Providing what I say is right.. i think that is the best
choice. :)
Simon.
---------
Formally Simon.J...@btinternet.com
Tom St Denis
That's one way, or there is another "smart" way. [asking too much I
suppose...]
The biggest failing AFAIK in AES is the algebraic style sbox. So to
improve AES w.r.t to algebraic attacks one should investigate changing
the sbox so it has a more complicated algebraic expression [e.g. more
terms].
Maybe a couple of more rounds are required to avoid saturation attacks
but just blindingly saying "use 3AES" is fairly blind.
Tom
Tom St Denis
Well you don't have to use a single 768-bit key. You could use a
256-bit key, write a decent key schedule and use the s^3 modified
sboxes. Voila single des which has a longer key size and resist DC/LC
better.
Tom
Mok-Kong Shen
It does seem that there are some misunderstanding (on
either my or your part). So let me be very precise.
Let's take DES. It accepts any given key K and uses
its key schedule to generate 16 round keys K_i
for use in the individual rounds. These are obviously
not independent from one another, right? Now, suppose
one has a good true random source and obtain from
it 16 keys R_i and substitute these in the otherwise
standard DES algorithm in place of the K_i, would that
operation make the crypto processing worse or better?
[To your last sentence: 'independent keys' are by
definition not 'related', isn't it?]
Thanks.
M. K. Shen
Mok-Kong Shen
Tom St Denis wrote:
>
> Mok-Kong Shen <mok-ko...@t-online.de> wrote:
In real life, one has often the choice between mild
measures and revolutionary ones. What I said is an
approach of the common (or little) man, who has not
much influence (or interest) to get the AES specification
changed by one dot. So using 3AES is a very handy
means of getting better security, if he feels somehow
uncertain about the security of AES, isn't it? That
has nothing to do with blindness in my view.
M. K. Shen
Michael Amling
> SCOTT19U.ZIP_GUY wrote:
>
>> Don't get me wrong its nice to have fast ciphers. But one should
>>also have ciphers where security counts for much more than speed.
>>Unfortunately as pointed out by many there is no real measure for
>>security but time is easy to measure. So as a result of being easy
>>in the making of new ciphers.
>
>
> I agree.
>
> I guess that there are some alternatives for those worried about the
> security of AES. One natural possibility might be Triple AES (hey,
> why not?).
Or use the AES finalist the NIST chose for security overkill over
speed, namely Serpent.
--Mike Amling
Mok-Kong Shen
jsa...@ecn.ab.ca wrote:
>
[snip]
One way to
> address this is what Terry Ritter had been suggesting: use a mixture of
> different ciphers.
Would you go so far as to employ multiple encryption
with stream cipphers and block ciphers? (Some good
stream cipher should eventually emerge from the NESSIE
project, if I don't err.)
M. K. Shen
Ursus Horibilis
> Ursus Horibilis wrote:
> >This is a bad choice for a counter-example [...]
>
> Maybe you'll like this better. Consider the following three algorithms:
> plain DES: E_k(x) = DES(k,x)
> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
> no more secure than plain DES.
I'm pretty sure this horse is dead, but given the slightest hope of a
possibility that it might jump up and decide to pull the buggy, let me flog
it one more time...
Way back at the beginning, I tried to establish that we were only comparing
optimally-implemented algorithms. I postulated that for each cipher there
is at least one implementation that transforms PT into CT in minimum time.
This is the same criterion expressed theologically by Mr. Scott when he
appointed God to be his programmer. For obvious reasons, one of which you
exhibited above, we only want to compare those implementations that meet
this criterion. It is as close as we can get to "all other things being
equal."
DES+no-ops drops out of the line-up since it is not one of the algorithms
that falls into the class of optimal implementations.
Mok-Kong Shen
Concerning the 'correlation' (or 'causation' or whatever)
between speed and strength, does anyone happen to have
speed measurements on the AES non-finalists? If yes, it
would be interesting to see if there could be some
useful information to be gained in the present context,
when a comparison with the AES finalists is done.
M. K. Shen
SCOTT19U.ZIP_GUY
online.de>:
>
>In real life, one has often the choice between mild
>measures and revolutionary ones. What I said is an
>approach of the common (or little) man, who has not
>much influence (or interest) to get the AES specification
>changed by one dot. So using 3AES is a very handy
>means of getting better security, if he feels somehow
>uncertain about the security of AES, isn't it? That
>has nothing to do with blindness in my view.
>
>
I don't trust AES I think there is a break. But that
doesn't mean a clever version of 3 AES much slower would
not make me fill more secure. Example
BICOM first AES key 1
reverse file
uncompress using one of the better bijective compressor
reverse file
BICON second AES key 2
reverse file
uncompress another grearer bijective compressor
BICOM third AES key 3
I would trust this much more than other implementationd
of 3AES
SCOTT19U.ZIP_GUY
>
> Or use the AES finalist the NIST chose for security overkill over
>speed, namely Serpent.
>
>
My trust factor is not that high. Its my view and my view
only that all those that made it to public view in this so called open
contest are most likely breakable by the NSA.
Secondly there is no way to tell how secure any of the ciphers
are. Unless there is a break and then its unsecure. So a finding that
Serpent was eliminated becuase of security overkill has to be some
sort of BS. In fact I hope that all these ciphers that made it to
this round get broken.
Mok-Kong Shen
"SCOTT19U.ZIP_GUY" wrote:
>
[snip]
> I would trust this much more than other implementationd
> of 3AES
For you certainly and very understandably. But for
others, in particular the common people, who cannot
be expected to know/learn about BICOM (which for
understandable or un-understandable reasons seems
unfortunately not yet to be favoured even by the
majority of our group), using 3AES is an easily
understandable and simple to implement measure
that should give a safety far beyond reasonable
doubt in my admittedly subjective estimation. Note
also that security is not provided by a cipher alone.
Implicit in the above is that 3AES is used 'properly'.
M. K. Shen
Edward Elliott
> The biggest failing AFAIK in AES is the algebraic style sbox. So to
> improve AES w.r.t to algebraic attacks one should investigate changing
> the sbox so it has a more complicated algebraic expression [e.g. more
> terms].
If you change the sboxes you could make AES significantly weaker. More
complicated does not equal more secure. Most of the research on AES
goes right out the window and you have to analyze the cipher all over
again. You might end up with something more secure, but it's a
tremendous amount of time and effort to reach the level of assurance AES
has now. Unless a major flaw were discovered in AES, you'd have a very
hard time attracting enough research capital (in terms of brainpower) to
do this.
Edward Elliott
Edward Elliott
> My trust factor is not that high. Its my view and my view
> only that all those that made it to public view in this so called open
> contest are most likely breakable by the NSA.
Even if that were true, _why_ would the NSA ever bother with you?
They're concerned with matters on an international scale: the rise and
fall of regimes, national security, global stability, etc. You don't
even show up on their radar (nor does anyone else here, I'm sure).
Edward Elliott
SCOTT19U.ZIP_GUY
>
>Even if that were true, _why_ would the NSA ever bother with you?
>They're concerned with matters on an international scale: the rise and
>fall of regimes, national security, global stability, etc. You don't
>even show up on their radar (nor does anyone else here, I'm sure).
>
>
I think they try to take an interest in anything related to crypto.
There job after all is to keep everyone in the dark about good crypto.
I am sure they belive they are doing the right thing. But what is
happening is that they are helping in the dummbing down of America.
I would bet a hundred dollars they have looked at scott19u. If they
haven't then they aren't doing there job. One problem with a group
like them is that they become smug thinking they are so much better
than every one else. That a lot of real talent is missed. They when
Clinton was in power become more of a poltical weapon for the abuse
of power. Concentrating on trying to help the liberals destroy america
when they should have spent more time on the islamists carzies and
the red chinese. And yes when I retired I did try to get a job with
them but they never bothered to even have the curtesy to answer back.
At least the NIST anwsered back a few times when I wrote about trying
to become part of the modes thing. But in the end they never allowed
my type to be a real part of it. Since it was more of less a closed
group which adds to my belied the whole AES project is nothing
more than a white wash.
I wish they that would focus more on the job of protecting the
free world instead of trying to protect those in power and trying
to keep people dumb. These are my views right or wrong.
Andrew Swallow
news:3D46CEA6...@bar.com...
[snip]
>
> Even if that were true, _why_ would the NSA ever bother with you?
> They're concerned with matters on an international scale: the rise and
> fall of regimes, national security, global stability, etc. You don't
> even show up on their radar (nor does anyone else here, I'm sure).
>
by CESG, up to and including TOP SECRET.
Option 1 - AES is a trap. It has a hidden weakness that NSA/GCHQ
know about. There are many third world countries that
could buy the equipment and use it for military or
diplomatic purposes.
Option 2 - AES is so strong that NSA and GCHQ cannot break it.
With IDEA around it is not worth while forcing banks
to use breakable ciphers. Particle when its your
own back account that is being protected.
Option 3 - AES is too strong for journalists to break, so it can
be used for all internal secrets and the protection of
Government Money. Option 1 still applies.
Andrew Swallow
Tom St Denis
> > That's one way, or there is another "smart" way. [asking too much I
> > suppose...]
> >
> > The biggest failing AFAIK in AES is the algebraic style sbox. So to
> > improve AES w.r.t to algebraic attacks one should investigate changing
> > the sbox so it has a more complicated algebraic expression [e.g. more
> > terms].
> >
> > Maybe a couple of more rounds are required to avoid saturation attacks
> > but just blindingly saying "use 3AES" is fairly blind.
>
> In real life, one has often the choice between mild
> measures and revolutionary ones. What I said is an
> approach of the common (or little) man, who has not
> much influence (or interest) to get the AES specification
> changed by one dot. So using 3AES is a very handy
> means of getting better security, if he feels somehow
> uncertain about the security of AES, isn't it? That
> has nothing to do with blindness in my view.
Lets do some role playing.
Your sitting in a meeting room discussing what cipher to implement as
part of your cryptosystem as part of your product.
You come accross the notion that standards are good but AES is too
weak. You decide on 3AES.
Now this is the point you realize that 3AES is not yet a standard and
in fact your are just doing "technical homebrew crypto".
And don't give me this "its a good idea" line of thinking. Sure 3AES
is likely to be tougher to attack [even in theory] then just plain AES
but 3AES is not a standard. I mean I could design a cipher that is
harder to attack than AES [not terribly hard]. That still won't be a
standard and therefore not widely accepted.
So the bottom line is either take what you got or diverge in sensibles
ways. E.g. If you really don't like AES don't use AES or use a
modification of it [and not claim its AES].
Tom
Edward Elliott
> Option 1 - AES is a trap. It has a hidden weakness that NSA/GCHQ
would be interested in monitoring David A Scott's traffic.
Edward Elliott
David Wagner
>"David Wagner" wrote:
>> Maybe you'll like this better. Consider the following three algorithms:
>> plain DES: E_k(x) = DES(k,x)
>> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
>> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
>> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
>> no more secure than plain DES.
>
>that falls into the class of optimal implementations.
Your post doesn't make sense to me. The obvious algorithm for computing
the "DES+no-ops" function using 4 DES encryptions is likely to be the
fastest way to compute this function. If you don't think it is, show
me a faster way to compute the DES+no-ops function.
(By the way, do you know the difference between functions, algorithms,
and implementations? It is probably a good idea to be precise about
this in this discussion.)
Mok-Kong Shen
Tom St Denis wrote:
>
[snip]
> So the bottom line is either take what you got or diverge in sensibles
> ways. E.g. If you really don't like AES don't use AES or use a
> modification of it [and not claim its AES].
Whatever you or I or many of us say in the group
isn't likely to affect the behaviour of the common
people, I think. But 3AES, if the common people who
do apply crypto ever get the idea, is likely to have
sort of seductive effect on them in my view, for
they are already familiar with 3DES and could thus
easily conceive and convince themselves of its
benefits. (Whether you or I or many of us is of the
same or the opposite view isn't going to play an
essential role, I suppose.)
M. K. Shen
Daniel Mehkeri
>
> "David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
> news:ai4f69$1q1q$1...@agate.berkeley.edu...
> > Ursus Horibilis wrote:
> > >This is a bad choice for a counter-example [...]
> >
> > Maybe you'll like this better. Consider the following three algorithms:
> > plain DES: E_k(x) = DES(k,x)
> > DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
> > triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
> > Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
> > no more secure than plain DES.
>
[...]
>
> DES+no-ops drops out of the line-up since it is not one of the algorithms
> that falls into the class of optimal implementations.
>
What's not optimal about it? You can make F_k(x) faster than G_k(x), then?
I don't see it, unless I'm missing something. DES_0(x) =/= x, right?
--
To email me, remove my head.
Ursus Horibilis
> Ursus Horibilis wrote:
> >"David Wagner" wrote:
> >> Maybe you'll like this better. Consider the following three
algorithms:
> >> plain DES: E_k(x) = DES(k,x)
> >> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
> >> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
> >> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
> >> no more secure than plain DES.
> >
> >DES+no-ops drops out of the line-up since it is not one of the algorithms
> >that falls into the class of optimal implementations.
>
> Your post doesn't make sense to me. The obvious algorithm for computing
> the "DES+no-ops" function using 4 DES encryptions is likely to be the
> fastest way to compute this function. If you don't think it is, show
> me a faster way to compute the DES+no-ops function.
>
Why would you want to use DES to encrypt with a legitimate key and then N
keys of 0? What does that do for you?
> (By the way, do you know the difference between functions, algorithms,
> and implementations? It is probably a good idea to be precise about
> this in this discussion.)
No, sir, I haven't a clue. So far as you're concerned, I know nothing about
any of those things and am merely throwing those terms around because it
gives me a warm and fuzzy feeling to confuse the devil out of other readers.
My only reason for posting to this newsgroup is to see if my newsreader is
working bidirectionally. I am a hopeless troll, and I would appreciate it
if you would save me from myself by adding me to your killfile as soon as
you possibly can. It will save so much misunderstanding and wasted
bandwidth in the future.
Edward Elliott
> Why would you want to use DES to encrypt with a legitimate key and then N
> keys of 0? What does that do for you?
Makes the cipher slower. That's about it (the point of this discussion,
no?).
>>(By the way, do you know the difference between functions, algorithms,
>>and implementations? It is probably a good idea to be precise about
>>this in this discussion.)
>
> No, sir, I haven't a clue. So far as you're concerned, I know nothing about
> any of those things and am merely throwing those terms around because it
> gives me a warm and fuzzy feeling to confuse the devil out of other readers.
He's not trying to insult you; these terms have precise technical
definitions that are slightly different from their common usage.
Understanding them will speed up the discussion. Agreeing on the
definition of terms is the first step of any well-founded argument.
Edward Elliott
David Wagner
>> >"David Wagner" wrote:
>> >> Maybe you'll like this better. Consider the following three
>algorithms:
>> >> plain DES: E_k(x) = DES(k,x)
>> >> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
>> >> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
>> >> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it is
>> >> no more secure than plain DES.
>
>keys of 0? What does that do for you?
What does it do for me? It makes it a valid counterexample. That's all
it needs to do. Sure, DES+no-ops is an artificial example -- it's
supposed to be. The point is that it is a counterexample to the claim
that "slower is always more secure".
Do you agree DES+no-ops is a counterexample to the claim that "slower
is always more secure"? That's all it was intended to be. It was not
intended to be something that any reasonable person would want to use.
A cynic might ask, do we really need to ask why anyone would want to
use DES+no-ops? Isn't the answer obvious? Why, because it's slower,
of course! That's the only conceivable reason to want to use DES+no-ops.
After all, if you believe that slower is more secure, if you believe that,
then surely DES+no-ops must be the best among the three choices I gave.
Of course, you and I both know that DES+no-ops is not the best choice,
despite the fact that it is the slowest. I think we can also agree that
slower is not necessarily more secure. I hope we can agree on that.
If so, I'm satisfied: that was the only reason I brought up the
"DES+no-ops" function.
If you look closely, you'll notice that DES+no-ops is even a
counterexample to the claim that "slower is more secure because it makes
exhaustive keysearch slower". Do you see why?
I hope this answers your questions.
Tom St Denis
Actually this is about the most wrong thing I have read so far this week.
The three primary attacks are trivial to figure out and one of which
doesn't even care what the sbox is.
The fourth attack is interpolation style attacks.
So really you could get the bulk of your security wise analysis done in
a matter of minutes. The bigger issue [which you missed alltogether] is
that a random 8x8 would make the cipher slower in hardware which is
another reason not todo it.
Tom
Richard Parker
> It does seem that there are some misunderstanding (on
> either my or your part). So let me be very precise.
> Let's take DES. It accepts any given key K and uses
> its key schedule to generate 16 round keys K_i
> for use in the individual rounds. These are obviously
> not independent from one another, right? Now, suppose
> one has a good true random source and obtain from
> it 16 keys R_i and substitute these in the otherwise
> standard DES algorithm in place of the K_i, would that
> operation make the crypto processing worse or better?
That depends on what criteria you take into consideration when selecting the
"better" block cipher.
Standard DES is vulnerable to differential cryptanalysis given about 2^47
chosen plaintexts. DES with independent round subkeys is vulnerable to
differential cryptanalysis given about 2^61 chosen plaintexts.
Standard DES is largely immune to related-key attack. DES with independent
round subkeys is vulnerable given a single related key and approximately
2^16 chosen plaintexts.
Standard DES is vulnerable to a brute-force exhaustive search requiring 2^55
work. DES with independent round subkeys is vulnerable to a brute-force
meet-in-the-middle attack requiring 2^384 work.
-Richard
David Wagner
>He's not trying to insult you; these terms have precise technical
>definitions that are slightly different from their common usage.
>Understanding them will speed up the discussion. Agreeing on the
>definition of terms is the first step of any well-founded argument.
Yes, that was exactly my intention. Thank you for stating it so
clearly; I did a poor job of communicating. It wasn't my intent to
insult anyone -- I'm sorry if I caused any confusion. I was mostly
concerned that the terminology might be causing some miscommunication.
For reference, here's what I think of when I hear the terms "function,
algorithm, implementation". I think of them as three levels of
abstraction. A function is the most abstract: it specifies only the
input-output behavior. An algorithm is in the middle: it describes
how to compute some function, but still at a reasonably abstract level.
An implementation is the most concrete: it describes how to instantiate
an algorithm on a specific machine, down to the level of the machine
instructions you execute to perform each step of the algorithm.
There may be many implementations of any given algorithm, and there
may be many algorithms that compute any given function. One can talk
about finding the optimal algorithm that computes any given function,
or even the optimal implementation of a specific algorithm. However,
I don't know how to make sense of statements like "This algorithm is a
sub-optimal implementation", as algorithms and implementations are at
different levels of the hierarchy. This may just be a difference in
the way people use these terms.
Paul Rubin
> Standard DES is largely immune to related-key attack.
Wha?? I've never heard that before, even ignoring the key
complementation property which is a trivial related key attack.
What's the story?
jsa...@ecn.ab.ca
: What does it do for me? It makes it a valid counterexample. That's all
: it needs to do.
Ah, but then the claim just has to be backed up slightly. "Slower" doesn't
mean slower when *I* carry out the cipher operation, but slower when an
attacker carries out the cipher operation for brute-force key search.
Thus, it just forces one to refine the definition of speed; it doesn't
refute what the people who say 'slower is more secure' are actually
thinking. Thus, it may be a valid counterexample, but it doesn't really
communicate insight into the question.
Instead of just redefining "slower" as "slower when speed is defined as
the speed of the fastest isomorphic algorithm", one wants to show how
slowness can fail to aid security, even where it _appears_ that the extra
time is being used conscientiously.
And it's easy enough to note that Round A might be slightly slower than
Round B, and yet be slightly less secure. It's only common sense that
security isn't an exact multiple of time, no matter what the structure of
the round is.
John Savard
Richard Parker
>> Standard DES is largely immune to related-key attack.
>
> Wha?? I've never heard that before, even ignoring the key
> complementation property which is a trivial related key attack.
> What's the story?
Yes, the well-known relation called the complementation property was the
reason for the "largely" in my statement. That simple relation reduces the
effective keyspace of DES by one bit.
While the DES key schedule has weaknesses, I am not aware of any published
paper describing a related-key attack on DES. While it isn't an indication
that other related-key attacks don't exist, Biham's paper on related keys
specifically mentions that DES is not vulnerable to his related-key attack
based on rotating the round subkeys (the original related-key attack that
worked against both LOKI and Lucifer). Also, neither of the two papers by
Kelsey, Schneier and Wagner on related-key cryptanalysis mention a
related-key attack on DES.
Am I missing something? If you know of a paper describing a related-key
attack on DES I would greatly appreciate a reference.
-Richard
David Wagner
It's right, as far as I know. I don't know of any effective
related-key attack on DES. Somehow, the key schedule seems to
kill any differentials you try to introduce into the key, and
prevents Biham's related-key slide attacks. (Biham showed that
if you use the same rotation amount in every round, instead of
this funny pattern 1,2,2,1,whatever, then DES becomes susceptible
to related-key attacks.) I don't know that it is well-understood
why DES resists related-key attacks so effectively; it's a bit of
a mystery to me.
SCOTT19U.ZIP_GUY
<3d46d65d$2...@pull.gecm.com>:
>"Edward Elliott" <f...@bar.com> wrote in message
>news:3D46CEA6...@bar.com...
>[snip]
>>
>> Even if that were true, _why_ would the NSA ever bother with you?
>> They're concerned with matters on an international scale: the rise and
>> fall of regimes, national security, global stability, etc. You don't
>> even show up on their radar (nor does anyone else here, I'm sure).
>>
>AES has been authorised for use in protecting UK Government Secrets
>by CESG, up to and including TOP SECRET.
Do you have a pointer for this since the US governmetn doesn't
trust it enough for even confidential data the loewest level
of classifed data.
David Hopwood
Richard Parker wrote:
> I think there could be other reasons that DES with independent round subkeys
> (your 768-bit longkey-DES) was not adopted as a replacement for DES. For
> example, the absence of a key schedule might also have been a concern.
> Consider the popular Davies-Meyer hash construction, the lack of key
> schedule makes DES with independent subkeys a very poor choice of a block
> cipher primitive for this construction.
The reason why Davies-Meyer is insecure in this case is that Davies-Meyer
requires unreasonably strong assumptions about the cipher. If it is "popular",
it doesn't deserve to be. Stick to dedicated or hash-based MACs, or schemes
based on block ciphers that can be proven secure assuming only that the
block cipher is indistinguishable from a PRP.
> I also recall that DES with independent subkeys can be broken with one
> related key and approximately 2^16 chosen plaintexts (or 15 related keys and
> 60 chosen plaintexts). Of course as a composition cipher 3DES itself is not
> immune to related key attack, but it is more resistant than DES with
> independent subkeys. Admittedly when just used as a cipher DES with
> independent subkey is unlikely to be vulnerable to such attacks due to
> largely impractical nature of related-key attacks.
In almost all cases protocols can be designed to make related-key attacks
on the symmetric algorithms they use *impossible*, not just "largely
impractical". This isn't rocket science; basically it just means generating
symmetric keys either at random or using a conservatively designed KDF, and
transporting them only over channels that ensure integrity.
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPUcsSjkCAxeYt5gVAQF1kAgArQpcKtLUfs/LQwrS5wnaVRuJA7BwABT9
CuWG0nacq96mIp2Cmvj5qpyzTd81lVM0/pPveq5mGEl6frnDRWxdnKoBab6q9cSN
M6uuCbj+5EZM2UUlovkFEJA2h86dG2ZwRSvwOOdmHlIWDUntCexcK5RXm2Gb2I1J
3U1UY9mLbxmePgjszLtuYYSKl0zUU0mDPZeP+k4LMTosJdvnlwy91xJMbTFbz9C/
hDWyV4aQYJJS5P4ftEHKSMZFpNV/poNj38vQzUP4vqDmk9luYTxcSUpQHk1HAssv
+/OuPwlB1Ppvnz6QySMIBYSGT2tbsDsAefeaQj2syAOjIWpwwJsjlg==
=pra6
-----END PGP SIGNATURE-----
David Hopwood
Mok-Kong Shen wrote:
> Richard Parker wrote:
> > No. I would expect a block cipher with independent round subkeys to be
> > vulnerable to related-key attacks.
[...]
> [To your last sentence: 'independent keys' are by
> definition not 'related', isn't it?]
No, 'independent' in this context means 'independently variable', not
'statistically independent'.
[PS. to translate German "nicht wahr?" into English, use the modal verb
and subject pronoun consistent with the preceding sentence, with the verb
negated but in the same tense and the same plural agreement. If the verb
is not modal, replace it with 'to do'. For example:
'Independent keys' are by definition not 'related', are they?
He didn't say that, did he?
He said that, didn't he?
That's not true, is it?
That's true, isn't it?
That will be true, won't it?
It couldn't have meant that, could it?
Alice sends encrypted messages every day, doesn't she?]
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPUczQjkCAxeYt5gVAQHMbQgAv9KjuuPM2fYkFVahIY3T8D+5P7RN+Duz
XN8fy2B4TEEW2zbX9jmJc7RiK8Dy9p5q+262JbYXihSXJRV7vIvqar8f1cZu+B4Z
DSPa/Z65I4pHE78UByHyQazG8gMOmYd/paYguHa8FVo68DcveWwHgiLOGkZeJYnj
ul/M25BtVF2/JIEndbkI66IBUDQiA/yZMaS5gMTldd0yfSiia72VYB7C6wkDboXw
YM8n5GkS/zrYM7DLAMkw1Op+77gt9sXBysviVx7r0mjogH0+fs/o9zHyOa4IG44z
aGSLrRes/YnodaHJyy+H8gd/uBnJS7JS6PlHUT95k/900jxPq+r9kw==
=nUQO
-----END PGP SIGNATURE-----
Richard Parker
> Well you don't have to use a single 768-bit key. You could use a
> 256-bit key, write a decent key schedule and use the s^3 modified
> sboxes. Voila single des which has a longer key size and resist DC/LC
> better.
Sure, but I think by the time you've designed a new key schedule, changed
the key size, modified the S-boxes and performed a security analysis of the
new design you will find that you have done a substantial portion of the
work you'd have had to do if you were designing a entirely new cipher.
-Richard
Richard Parker
> The reason why Davies-Meyer is insecure in this case is that Davies-Meyer
> requires unreasonably strong assumptions about the cipher. If it is "popular",
> it doesn't deserve to be. Stick to dedicated or hash-based MACs, or schemes
> based on block ciphers that can be proven secure assuming only that the
> block cipher is indistinguishable from a PRP.
Oh I agree, I think a dedicated hash function like SHA-1 is to be strongly
preferred over the Davies-Meyer hash construction.
However, if the only cryptographic primitive one has access to is a block
cipher, one's options are limited. Unfortunately, as Black, Rogaway and
Shrimpton claim in their recent paper on block-cipher-based hash functions,
there doesn't appear to be any proof in today's literature for the
collision-resistance of any hash function based on a block cipher under any
formalized model other than their own paper which uses the black-box model.
Despite the flaws of the Davies-Meyer construction Black, Rogaway and
Shrimpton do provide a proof of its collision-resistance in the black-box
model and for reasons that are unclear to me the Davies-Meyer construction
is the most frequently mentioned construction when discussing building a
hash from a block cipher.
> In almost all cases protocols can be designed to make related-key attacks
> on the symmetric algorithms they use *impossible*, not just "largely
> impractical". This isn't rocket science; basically it just means generating
> symmetric keys either at random or using a conservatively designed KDF, and
> transporting them only over channels that ensure integrity.
Again I agree. In practice the only case where I've seen an actual
related-key attack on a deployed protocol the attack was only possible due
to an implementation flaw in a hardware RNG and not due to a technical flaw
in the protocol. Even then, the attack required the adversary to have a
degree of access to the RNG that was considered impractical.
-Richard
Michael Amling
> [PS. to translate German "nicht wahr?" into English, use the modal verb
> and subject pronoun consistent with the preceding sentence, with the verb
> negated but in the same tense and the same plural agreement. If the verb
> is not modal, replace it with 'to do'. For example:
>
> 'Independent keys' are by definition not 'related', are they?
> He didn't say that, did he?
> He said that, didn't he?
> That's not true, is it?
> That's true, isn't it?
> That will be true, won't it?
> It couldn't have meant that, could it?
You mean "It couldn't have meant that, could've it?"
--Michael "Meik" Amling
David Hopwood
Michael Amling wrote:
> David Hopwood schrieb:
> > PS. to translate German "nicht wahr?" into English, use the modal verb
> > and subject pronoun consistent with the preceding sentence, with the verb
> > negated but in the same tense and the same plural agreement. If the verb
> > is not modal, replace it with 'to do'. For example:
> >
> > 'Independent keys' are by definition not 'related', are they?
> > He didn't say that, did he?
> > He said that, didn't he?
> > That's not true, is it?
> > That's true, isn't it?
> > That will be true, won't it?
> > It couldn't have meant that, could it?
>
> You mean "It couldn't have meant that, could've it?"
No, at least in British English, "could it have?" is OK as an alternative,
but "could've it?" sounds ungrammatical (although I'm not sure what the
precise rule is). Follow-ups to alt.usage.english.
- --
David Hopwood <david....@zetnet.co.uk>
Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQEVAwUBPUd9TzkCAxeYt5gVAQEndgf/Wju1Roygewgu5/t3hvXutO6UGlz6Q4/e
oWvscrtyrepAFc/hwltr7XaJoZMY10wlweF0KzML8hIyxPlfckrZRcpZebBhPtED
bqo/8EH0FD1fqfnrrP4QAgcbMLOpg5OgVxKm4n3JuRTEKFgfygAvwl/O+42/8TJn
ixu6oF+46vL3/fodple5EvzDFx2Pf8O7YI9SOvl7ry3c28v2McKTB6hNtubRRzeD
LIbWuw6qgoXTNAGoBz1tf1U5mbO2oITU3JeeJFHe0AMcN3/pErDGg+L5bwIHG6AC
C+pJGeBXAPhKHXI6FDqgViHkhxoUMSMP57kOhwNzjMrph7pUDYkBxA==
=y7JJ
-----END PGP SIGNATURE-----
Mok-Kong Shen
Thanks. If I understand right, your 2nd and 4th paragraph
above seem to confirm my guess that independent round keys
are in general better. However, I don't yet understand
your sentence in the 3rd paragraph: 'DES with independent
round subkeys is vulnerable given a single related key
and .....'. What do you mean by 'a single realted key'
(or perhaps 'a pair of related keys') here? Is that the
user-given key (the key, not any round key)? For
two encryption runs, if the user-given keys K1 and
K2 are different, then there are two corresponding
different sets of round keys S1 and S2. If K1 and K2
are in some sense related, S1 and S2 would be related.
But in the independent round key case, we are
considering sets S1' and S2' that are 'entirely'
independent, there being no relationships whatever
not only between S1' and S2' but also within these
sets themselves (for they are assumed to be obtained
from good random sources).
M. K. Shen
M. K. Shen
Mok-Kong Shen
David Hopwood wrote:
>
> No, 'independent' in this context means 'independently variable', not
> 'statistically independent'.
Sorry for my poor knowledge. I am even more confused.
I understand 'independent' in the sense defined in
statistical textbooks. But what is 'independently
variable'? How is that to be understood mathematically?
Could you please elaborate a little bit, perhaps also
with examples, or else give a good pointer? Thanks.
M. K. Shen
Simon Johnson
> > My trust factor is not that high. Its my view and my view
> > only that all those that made it to public view in this so called open
> > contest are most likely breakable by the NSA.
> Even if that were true, _why_ would the NSA ever bother with you?
> They're concerned with matters on an international scale: the rise and
> fall of regimes, national security, global stability, etc. You don't
> even show up on their radar (nor does anyone else here, I'm sure).
>
<conspiracy>
Because the NSA dont do that.. The NSA get intelligence on Canadian
grain producers and give it to American grain producers so they can
under-cut their prices. National Security has many meanings.. one of
which is financial security.
</conspiracy>
I do not like the NSA and i don't like the idea of them having the
capability to read my SSL encrypted credit card transactions. I would
not use a system I know they could break..
Simon.
----
Formally Simon.J...@btinternet.com.
Tom St Denis
In design but the implementation of the core cipher itself would be
similar. In fact in hardware the rate of encryption could be identical.
Tom
Ursus Horibilis
> Ursus Horibilis wrote:
> >> >"David Wagner" wrote:
> >> >> Maybe you'll like this better. Consider the following three
> >algorithms:
> >> >> plain DES: E_k(x) = DES(k,x)
> >> >> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
> >> >> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
> >> >> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it
is
> >> >> no more secure than plain DES.
> >
> >Why would you want to use DES to encrypt with a legitimate key and then N
> >keys of 0? What does that do for you?
>
> What does it do for me? It makes it a valid counterexample. That's all
> it needs to do. Sure, DES+no-ops is an artificial example -- it's
> supposed to be. The point is that it is a counterexample to the claim
> that "slower is always more secure".
>
That's what I wanted to know. I thought I was missing something.
> Do you agree DES+no-ops is a counterexample to the claim that "slower
> is always more secure"? That's all it was intended to be. It was not
> intended to be something that any reasonable person would want to use.
>
I don't agree that it makes a counter-example to the claim that "slower is
more secure" and I think that the claim "slower is *always* more secure" is
unsupportable. In your list of cipher-systems, you have ordered them
according to increasing security. I think we agree on that. If we compare
DES to 3DES, I think we'll agree that 3DES is slower and more secure than
DES. If we compare DES to "DES+no-ops", I think we'll agree that
"DES+no-ops" is slower and more secure than DES. It's only when we compare
"DES+no-ops" to 3DES that we find an example of a cipher that is faster and
more secure.
This last comparison is a counter-example to the statement "slower is
*always* more secure". The previous two tend to support the assertion that
"slower is *often* more secure."
The more subtle point here is that there is some sort of implication that we
can quantify "secure", which we can't. Yet we persist in statements like
"3DES is more secure than DES." What is our basis for such statements. You
can't brute-force 3DES but you can brute-force DES. You can't brute-force
AES either. So is AES more or less secure than 3DES?
I can postulate two crypto-systems, one using AES at its core, the other
using 3DES. These two systems both have the same flaw that makes them
vulnerable to dictionary attacks. Given that AES and 3DES and all the
supporting infrastructure are implemented optimally, which one do you think
will crack first? I think it will be AES, simply because it's faster in
several dimensions. Does that mean that AES is less secure than 3DES? I
don't know, but in this particular crypto system, it was the poorer choice.
Mok-Kong Shen
Simon Johnson wrote:
>
> <conspiracy>
> Because the NSA dont do that.. The NSA get intelligence on Canadian
> grain producers and give it to American grain producers so they can
> under-cut their prices. National Security has many meanings.. one of
> which is financial security.
> </conspiracy>
[smip]
To be fair, I suppose that one should mention that
secret agencies of many (presumably all) other
countries of the world are going similar things, even
if they may not have equally high material, technical
and intellectual resources. Assuming that these are
anyhow bound by morals/ethics would be at least as
questionable as (if not more questionable than)
assuming that all clergymen are morally impeccable
persons.
M. K. Shen
Anne & Lynn Wheeler
> To be fair, I suppose that one should mention that
> secret agencies of many (presumably all) other
> countries of the world are going similar things, even
> if they may not have equally high material, technical
> and intellectual resources. Assuming that these are
> anyhow bound by morals/ethics would be at least as
> questionable as (if not more questionable than)
> assuming that all clergymen are morally impeccable
> persons.
back in early to mid '80s when the large computer company i was
working for starting looking at allowing people to access email while
traveling ... a vulnerability assesement highlighted hotel PBXs as one
of the most vulnerable points. as a result, the company built custom
2400baud modems that included session key generation and exchange and
des encrypted transmission.
at least corporate espionage was issue in the US ... and both
corporate and gov. espionage was issue outside the US. I seem to
remember something in the news from the period about gov. agents in
some european country going thru hotel rooms as part of industrial
espionage efforts.
evem prior to the "road warrior" issue .... all of the telco lines for
internal corporate network required link encrypters (for some period,
the claim was that half of all link encrypters in the world were
installed on the internal network, that claim may have been qualified
with "non-gov" ... i don't remember) .. . I remember this causing some
issues with gov/PPTs in europe ... especially lines that crossed
country borders.
--
Anne & Lynn Wheeler | ly...@garlic.com - http://www.garlic.com/~lynn/
Ursus Horibilis
"Simon Johnson" <Ck...@hotmail.com> wrote in message
news:f5668ae7.02073...@posting.google.com...
> <conspiracy>
> Because the NSA dont do that.. The NSA get intelligence on Canadian
> grain producers and give it to American grain producers so they can
> under-cut their prices. National Security has many meanings.. one of
> which is financial security.
> </conspiracy>
>
You know, I really wish I could believe that. It would make me feel so much
better about the tax burden I am carrying.
Nowadays, grain producers don't need the NSA to make questionable
projections on what Canadian grain producers might do. There are many more
useful and credible sources of information readily available to grain
producers all over the world. So take your Canadian grain and keep making
Canadian Club out of it. We'll keep shipping ours to Russia (at least until
they get to a point where they can meet their own needs--then they'll start
making Canadian Club and you'll have two more things to worry about).
Mok-Kong Shen
Paul Vigay wrote:
>
> Why worry about thinking of things they 'might' be snooping on or wanting
> to find out, when you can encrypt everything and make sure that your
> communications ARE safe.
Since sometime I have doubt whether encryption wouldn't
'defacto' be forbidden very soon. I heard that in UK the
police could now imprison persons without court orders
for arbitrarily long periods. My interpretation of a
recent news article on the net is that in US a person
could now be arrested and denied the right of being
defended by his lawyers through declaring him to be an
enemy combattant. Such and perheps more draconian
rules/regulations would in my view eventually suffice
to scare people away from employing any encryption at
all, as any piece of ciphertext could be a source for
suspicion of being involved with crimes and terrorism.
M. K. Shen
Ursus Horibilis
"Mok-Kong Shen" <mok-ko...@t-online.de> wrote in message
news:3D47F50F...@t-online.de...
>
>
> Paul Vigay wrote:
> >
>
> > Why worry about thinking of things they 'might' be snooping on or
wanting
> > to find out, when you can encrypt everything and make sure that your
> > communications ARE safe.
>
> Since sometime I have doubt whether encryption wouldn't
> 'defacto' be forbidden very soon. I heard that in UK the
> police could now imprison persons without court orders
> for arbitrarily long periods. My interpretation of a
> recent news article on the net is that in US a person
> could now be arrested and denied the right of being
> defended by his lawyers through declaring him to be an
> enemy combattant.
Yes. They have classified the so-called "Dirty Bomber" as a "terror
suspect" (whatever that means) and thrown him in the National Naval Brig in
Charleston, SC. This helps insure that he won't have any need for, or
access to, legal advice. According to a recent (two days ago) news report,
more "terror suspects" may join him soon.
> Such and perheps more draconian
> rules/regulations would in my view eventually suffice
> to scare people away from employing any encryption at
> all, as any piece of ciphertext could be a source for
> suspicion of being involved with crimes and terrorism.
>
Aw, c'mon. Have you got cold feet about standing up to "The Federation?"
Daniel Mehkeri
>
> "David Wagner" <d...@mozart.cs.berkeley.edu> wrote in message
> news:ai6v22$2dmn$1...@agate.berkeley.edu...
> > Ursus Horibilis wrote:
> > >> >"David Wagner" wrote:
> > >> >> Maybe you'll like this better. Consider the following three
> > >algorithms:
> > >> >> plain DES: E_k(x) = DES(k,x)
> > >> >> DES+no-ops: F_k(x) = DES(0,DES(0,DES(0,DES(k,x))))
> > >> >> triple DES: G_k(x) = DES(k1,DES(k2,DES(k3,x)))
> > >> >> Which one is most secure? Well, "DES+no-ops" is the slowest, yet it
> is
> > >> >> no more secure than plain DES.
> > >
>
> > Do you agree DES+no-ops is a counterexample to the claim that "slower
> > is always more secure"? That's all it was intended to be. It was not
> > intended to be something that any reasonable person would want to use.
> >
>
> I don't agree that it makes a counter-example to the claim that "slower is
> more secure" and I think that the claim "slower is *always* more secure"
> is unsupportable. In your list of cipher-systems, you have ordered them
> according to increasing security. I think we agree on that. If we
> compare DES to 3DES, I think we'll agree that 3DES is slower and more
> secure than DES. If we compare DES to "DES+no-ops", I think we'll agree
> that "DES+no-ops" is slower and more secure than DES. It's only when we
> compare "DES+no-ops" to 3DES that we find an example of a cipher that is
> faster and more secure.
No. I think David is asserting that DES+no-ops is NOT more secure than
DES, and this looks to be correct to me. Even though the cipher is
optimally implemented, it takes longer to compute without increasing the
time to attack -- not even by a linear amount.
--
To email me, remove my head.
Ursus Horibilis
"Daniel Mehkeri" <fo...@kvackmyhead.org> wrote in message
news:Pine.GSO.4.44.020731...@victoria.swi.com...
I will continue to believe that "DES+no-ops" as Wagner defined it will
always take longer to succumb to certain types of attack than will DES.
"DES+no-ops" is not a particularly good name for his example cipher system
since, as someone else pointed-out, encrypting with DES and a key of 0 is
not a NULL operation. To perform a dictionary attack, for example, you
still have to remove 3 layers of encryption with the 0-key before you get to
try the real key. This is bound to take longer than simply trying a key.
If it takes you 2 days to crack DES, it should take you 8 days to crack
"DES+no-ops".
Mok-Kong Shen
Ursus Horibilis wrote:
>
> "Mok-Kong Shen" <mok-ko...@t-online.de> wrote:
> > Such and perheps more draconian
> > rules/regulations would in my view eventually suffice
> > to scare people away from employing any encryption at
> > all, as any piece of ciphertext could be a source for
> > suspicion of being involved with crimes and terrorism.
> >
>
> Aw, c'mon. Have you got cold feet about standing up to "The Federation?"
No problem with my own feet. For discussions about
crypto would with fairly high probability remain free as
it currently is, only that the 'practice' of encryption
would 'defacto' be forbidden. (If ever I had some need
to secretly communicate, I could have used personal
couriers, I think, thus circumventing electronic
surveillance.) I can see here some analogy with certain
countries under dictatorship (conspicuous examples are
historical) with claimed (often even explicitly highly
stressed) democracy and freedom for their citizens.
M. K. Shen
Andrew Swallow
news:925BB63EBH110W...@216.168.3.40...
> andrew....@eatspan.baesystems.com (Andrew Swallow) wrote in
> <3d46d65d$2...@pull.gecm.com>:
>
> >"Edward Elliott" <f...@bar.com> wrote in message
> >news:3D46CEA6...@bar.com...
> >[snip]
> >>
> >> Even if that were true, _why_ would the NSA ever bother with you?
> >> They're concerned with matters on an international scale: the rise and
> >> fall of regimes, national security, global stability, etc. You don't
> >> even show up on their radar (nor does anyone else here, I'm sure).
> >>
> >AES has been authorised for use in protecting UK Government Secrets
> >by CESG, up to and including TOP SECRET.
>
> Do you have a pointer for this since the US governmetn doesn't
> trust it enough for even confidential data the loewest level
> of classifed data.
>
>
Remember we could be dealing with a trap.
http://www.cesg.gov.uk/partnerships/pwi/caps/capsprods.htm
http://www.cesg.gov.uk/partnerships/pwi/caps/products/
data-encryption/kilgettyNT4.htm
(You will have to rejoin the second link up)
As for the US Government AES was only given approval
this year. The British Government uses other cryptos
for military and diplomatic communications.
Andrew Swallow
Andrew Swallow
> 'defacto' be forbidden very soon. I heard that in UK the
> police could now imprison persons without court orders
> for arbitrarily long periods.
A non UK Citizen can be imprisoned
indefinitely if he is deported but refuses to leave
the UK. The asylum seeker has to object
to deportation on the grounds that he will be killed
if he returns to his own country. To get out of
prison, the person simply has to agree to
leave the UK.
Andrew Swallow
John Myre
<snip>
> I will continue to believe that "DES+no-ops" as Wagner defined it will
> always take longer to succumb to certain types of attack than will DES.
> "DES+no-ops" is not a particularly good name for his example cipher system
> since, as someone else pointed-out, encrypting with DES and a key of 0 is
> not a NULL operation. To perform a dictionary attack, for example, you
> still have to remove 3 layers of encryption with the 0-key before you get to
> try the real key. This is bound to take longer than simply trying a key.
> If it takes you 2 days to crack DES, it should take you 8 days to crack
> "DES+no-ops".
No; you remove the outer 3 layers once at the beginning, not for every
key you test. The same is true for any type of attack - you spend a
trivial amount of time at the beginning turning the ciphertext into
single-DES ciphertext, and then procede as for single DES.
JM
Douglas A. Gwyn
> ... The NSA get intelligence on Canadian grain producers and give it
> to American grain producers so they can under-cut their prices.
You would think that the Canadian part of the operation would
have a problem with that. What evidence do you have that it occurs?