Cryptography-Digest Digest #281, Volume #12 Mon, 24 Jul 00 18:13:00 EDT
Contents:
CypherCalc - Any good? (Doug Stell)
Re: AESC-stream cipher (Jerry Coffin)
MD5 Collision Resistance (Paul Martin)
Re: Q: Cascading multiple block algorithms (Bryan Olson)
Re: RC4-- repetition length? (Simon Johnson)
Re: RC4-- repetition length? ("Joseph Ashwood")
Another cipher, ready to be shot down. (Simon Johnson)
Re: MD5 Collision Resistance (S. T. L.)
Re: Q: Cascading multiple block algorithms (Mok-Kong Shen)
Re: New stream cipher (Mok-Kong Shen)
book announcement (Jud Wolfskill)
Re: AESC-stream cipher (Mok-Kong Shen)
Re: Random Appearance (Mok-Kong Shen)
Re: Q: Cascading multiple block algorithms ("Joseph Ashwood")
School question for you regulars. ("The Gorf")
Re: PGP US Versions Broken,no good?? (Simon Johnson)
Re: Practical application of Ciphersaber (Was: RC4-- repetition length?) (Bill Unruh)
Re: RC4-- repetition length? (Bill Unruh)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Doug Stell)
Subject: CypherCalc - Any good?
Date: Mon, 24 Jul 2000 15:49:24 GMT
We are considering the purchase of CypherCalc for the generation of
public key test vectors. Does anybody have an opinions on this
product?
If there are other products, preferably Windows based, that you know
of, please send me a pointer. We've tried UBASIC and PARI with no
success and I have not been able to locate any others.
You may reply here or send me email at [EMAIL PROTECTED]
thanks.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Mon, 24 Jul 2000 10:35:48 -0600
In article <8lhbn8$h1v$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Performance of this implementation is 190 Mbyte/sec.
> It was measured sending 256 byte in loop 777215 times.
This still means absolutely nothing: you've GOT to provide reasonably
complete specs on the machine and the data involved for a
specification of performance to mean anything.
To get an idea of real performance, I did a benchmark myself. I
grabbed a copy of one of the many programs from your website
(aesc.zip) and after looking over the source code, I used your
program to encrypt a large file (136,314,880 bytes). Averaging over
three runs, this took 150.1 seconds. I then timed making a simple
copy of the same file. This took 29.2 seconds. Subtracting the two,
I got a time of approximately 120.9 seconds for the actual
encryption. Dividing that by the amount of data, I got a speed of
barely over one megabyte per second.
This testing was done on a 400 MHz Pentium II with 256 Megabytes of
RAM. There were a number of other processes on the machine, using a
total of approximately 3% of the CPU bandwidth. Given the testing
methodology, I don't think the disk speed makes any real difference.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Paul Martin <[EMAIL PROTECTED]>
Subject: MD5 Collision Resistance
Date: Mon, 24 Jul 2000 12:48:32 -0400
Hi,
I'm currently investigating different hashing algorithms for use of
primary keys in our database. Having sequences is simply not an option
because of the tremendous difficulty of keeping numbers distinct in a
distributed environment, so we though hashing distinct values could solve
the problem.
We're sort of sold on MD5 already because of it's speed and 128-bit
result. Our internal benchmarks were really impressive for MD5. There
will be a large amount of data to hash on a regular basis: Our primary
requirements are speed and collision-resistance.
There's a few snags, of course, or I wouldn't be here.
First, we need a general idea of MD5's collision resistance. In an
ideal, perfect world, we could expect 2^128 different possible hash
values, and since the distinct value we're hashing are in the order of
10^10 I'm not expecting too many collisions. But that's the problem, I'm
*expecting*, I have no idea just exactly how often collisions will
happen, for all I know there's only 2^64 (or some other number) REAL
distinct MD5 values.
Another problem is we need to not know the original pre-hashed value. In
order to keep this value secret from ourselves (as well as everybody
else, obviously), but still be able to have a distinct and unique value,
I figured we'd do something like this.
(dots are concatenations)
Let Z be the original (secret) distinct value
Let K be a secret text
Let H be the MD5 digest
Let J be a controlled, one byte value
then
J.[H(K.Z)]
should produce up to (2^8)(2^128) values, depending on the collision
resistance of MD5. This is way more than we'll ever need, but it's
always good to be safe, and it (greatly) helps avoid collisions.
My primary concern with this particular method is the wisdom of
concatening K and Z together to keep the values secret. I'm fairly
certain How would you make *sure* that Z is always kept secret in a way
that system performance doesn't suffer too much?
Thanks for any help you can provide,
Paul
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Q: Cascading multiple block algorithms
Date: Mon, 24 Jul 2000 18:13:44 GMT
Mok-Kong Shen
>
> Bryan Olson wrote:
>
> > Mok-Kong Shen wrote:
> > > Mok-Kong Shen wrote:
> > > > In Schneier's AC, p.367, about cascading two block ciphers it
> > > > is stated:
> > > >
> > > > If the second algorithm is vulnerable to a chosen-plaintext
> > > > attack, then the first algorithm might facilitate that
> > > > attack and make the second algorithm vulnerable to a known-
> > > > plaintext attack when used in a cascade.
> > >
> > [...]
> > > Now that input is the output from the first algorithm. It
> > > cannot be directly chosen but only indireclty through choosing
> > > input to the first algorithm. This indirectness, assuming that
> > > the first algorithm has any strength at all, evidently means
> > > that the said attack is now more difficult.
> >
> > The statement doesn't say there's any realistic chance of
> > this happening. It's a possibility we cannot disprove, and
> > we can create contrived situations to illustrate it, but we
> > certainly don't expect it with reasonable ciphers.
> >
> > In known plaintext attack, the attacker is limited to the
> > given plaintext distribution. Putting another cipher in
> > front could result in a distribution much worse for the
> > second cipher. Suppose you have a block cipher that's very
> > strong if the first bit of the plaintext block is always 0,
> > but terrible when the first bit is one. It's vulnerable to
> > chosen plaintext, but when used to send ASCII text it's
> > strong.
>
> However, 'chosen-plaintext attack' without further qualification
> means to the reader that it is the general case, i.e. the analyst
> can choose ANY plaintext he likes.
Yes.
> With an intermediate (first)
> algorithm, his choice of the input to the second algorithm is
> evidently limited, unless he has already cracked the first algorithm
> somehow. Anyway, the presence of the first algorithm (which is at
> issue in the present context) can't have any negative effect on
> the second algorithm in aspect of its susceptibility to chosen-
> plaintext attack (with the term understood as such).
So adding the first algorithm (assuming independant keys)
will not result in a chain weaker against chosen plaintext
than is the second algorithm alone. By "facilitate the
attack" Schneier means provide an opportunity to launch it
where the system did not directly allow the attacker to
choose plaintext.
> While AC does refer to the attack as a 'potential attack', it says:
>
> If you let someone lese specify any algorithm which is
> used on you message before encryption, then you had
> better be sure that your encryption will withstand a
> chose-plaintext attack.
>
> which sounds like that the possibility discussed is not entirely
> imaginary/theoretical but could indeed very well happen in actual
> practice.
The problem here is not that two ciphers combined are likely
to be weaker, but that the "any algorithm" need not be a
realistic cipher, and the "someone" may even be the attacker.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Subject: Re: RC4-- repetition length?
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 24 Jul 2000 11:34:17 -0700
would say making 12 or 16 bit RC4 varients lead to an increase
general increase in the period of the cipher?
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RC4-- repetition length?
Date: Mon, 24 Jul 2000 11:54:53 -0700
I am quite sure that there is no entropy of any kind being inserted into the
key stream, and I am quite sure that as the length gets longer that same
amount of entropy must be applied over increasing distances, so while the
total randomness is certainly not increasing, it must therefore be remaining
the same, or decreasing. Therefore as the length increases, the entropy per
bit must decrease. There isn't much more that can be done to clarify it. I'm
quite sure that there exists a way to break it, I don't know how, no one may
know how, we may never know how, but the solution exists, there may be one
that is shorter, but we can be assured that one exists at that point.
Basically I'm just encouraging that you rekey your cipher (no matter which
one you choose) after a reasonable amount of data, in the RC4 case, 1 GB is
currently a safe bound, later this value may have to be reviewed. Of course
this also assumes that there is some requirement of strong cryptographic
protection, which may or may not be true.
Joe
------------------------------
Subject: Another cipher, ready to be shot down.
From: Simon Johnson <[EMAIL PROTECTED]>
Date: Mon, 24 Jul 2000 12:35:36 -0700
Take a look at www.dimension.h3o.org/~pabalo/SC3.pdf
It a lovely little block cipher.......
I've tried to learn from the mistakes of the previous cipher i
posted :)
Thanxs,
S Johnson
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: MD5 Collision Resistance
Date: 24 Jul 2000 19:54:03 GMT
<<We're sort of sold on MD5 already because of it's speed and 128-bit
result.>>
Or you could use the much more trustworthy SHA-1. Last I heard, MD5 was on its
last legs.
<<First, we need a general idea of MD5's collision resistance.>>
MD5 is good; SHA-1 is better.
<<I'm not expecting too many collisions.>>
Better not find ANY, even for MD5.
<<Another problem is we need to not know the original pre-hashed value. >>
Just hash it and don't look at the input. You know what cryptograpically
secure one-way hash means?
<<Let Z...>>
Useless.
<<depending on the collision
resistance of MD5. This is way more than we'll ever need>>
You could use SHA-1.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My Book Reviews Page * http://sciencebook.cjb.net * contains reviews of
ALL of my 169 science books, with ratings as well.
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Q: Cascading multiple block algorithms
Date: Mon, 24 Jul 2000 22:56:16 +0200
Bryan Olson wrote:
> Mok-Kong Shen wrote:
> >
> [snip]
>
> > With an intermediate (first)
> > algorithm, his choice of the input to the second algorithm is
> > evidently limited, unless he has already cracked the first algorithm
> > somehow. Anyway, the presence of the first algorithm (which is at
> > issue in the present context) can't have any negative effect on
> > the second algorithm in aspect of its susceptibility to chosen-
> > plaintext attack (with the term understood as such).
>
> So adding the first algorithm (assuming independant keys)
> will not result in a chain weaker against chosen plaintext
> than is the second algorithm alone. By "facilitate the
> attack" Schneier means provide an opportunity to launch it
> where the system did not directly allow the attacker to
> choose plaintext.
Many thanks for providing certain explanations. But at this point I
still have a question: If the system does not directly allow the
oppoent to choose plaintext (to the cascade, i.e. input to the first
algorithm), then he has even less opportunity to exert influence on
what the second algorithm gets as input. So 'facilitate the attack'
on the second algorithm in the sense of 'chosen plaintext', i.e.
arbitrarily choosing its input, seems to be far from being true in
my view. (I exclude the obvious nonsense case that both
algorithms were 'designed' by the opponent.)
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: New stream cipher
Date: Mon, 24 Jul 2000 22:56:25 +0200
[EMAIL PROTECTED] wrote:
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>
> > Do I understand correctly that you build up a substitution table of
> > 256*256 to transform the plaintext bytes according to group
> > multiplication (the entries are product of row and column entries).
> > So a plaintext character is used as the row entry and a key character
> > is used as the column entry and the ciphertext character is the
> > matrix entry. Questions:
> >
>
> Right.
>
> > (1) Which group of order 256 do you use? Would it be better/worse
> > to have in the table instead columns that are random
> permutations?
>
> This is the cyclic group of the order 256.
> Its isomorph table of relates to a permutation.
> Rendom colums do not give me solution for a*x=b as
> group feature.
> Certainly another finite groups may be used instead
> of cyclic one.
If you use the cyclic group then indeed you are using the plain
Vigenere table (for bytes). This is however generally considered to
be the weakest form of substitution tables, the transformation done
by the key (as mentioned by you below) notwithstanding.
> > (2) Which group of order 65536 do you use? How do you generate
> > the key stream? Does this key stream depend on its turn on a
> > specific secret key agreed upon by the communication partners?
> > How? This key stream must have a finite period. How large is
> that?
> >
>
> In this case we use cyclic group of the order 65536.
> But this may be any other group of the same order.
> 1. Both groups are transformed due to
> key.
> 2. Key is used as input of chain encryption using
> group of the order 65536 and word architecure.
> Word output stream of key generator is used as
> byte stream for encryption using group of the
> order 256.
> 3. Finite period of key stream may be anys from the
> set of cycles of the group of the order 65536.
> So the period is not known if key is secret.
How do you transform the cyclic group of order 65536? Do you
perform a linear transformation? (Are you working effectively
with a linear congruential generator?) If not, is there risk of getting
very short period? What are the general statistical properties of the
key stream? I mean all these points must be well clarified.
M. K. Shen
------------------------------
Date: Mon, 24 Jul 2000 17:10:49 -0400
From: Jud Wolfskill <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: book announcement
I thought readers of this list might be interested in this book. For
more information please visit
http://mitpress.mit.edu/promotions/books/CAMTHF99
Trust and Risk in Internet Commerce
L. Jean Camp
As Internet-based commerce becomes commonplace, it is important that we
examine the systems used for these financial transactions. Underlying
each system is a set of assumptions, particularly about trust and risk.
To evaluate systems, and thus to determine one�s own risks, requires an
understanding of the dimensions of trust: security, privacy, and
reliability.
In this book Jean Camp focuses on two major yet frequently overlooked
issues in the design of Internet commerce systems--trust and risk. Trust
and risk are closely linked. The level of risk can be determined by
looking at who trusts whom in Internet commerce transactions. Who will
pay, in terms of money and data, if trust is misplaced? When the
inevitable early failures occur, who will be at risk? Who is "liable"
when there is a trusted third party? Why is it necessary to trust this
party? What exactly is this party trusted to do? To answer such
questions requires an understanding of security, record-keeping,
privacy, and reliability.
The author�s goal is twofold: first, to provide information on trust and
risk to businesses that are developing electronic commerce systems; and
second, to help consumers understand the risks in using the Internet for
purchases and show them how to protect themselves. Rather than propose a
single model of an Internet commerce system, the author provides the
information and insights needed by merchants and consumers as they
develop the Internet for commerce.
L. Jean Camp is Assistant Professor at Harvard University�s Kennedy
School of Government.
6 x 9, 292 pp., 25 illus., cloth ISBN 0-262-03271-6
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: AESC-stream cipher
Date: Mon, 24 Jul 2000 23:24:25 +0200
[EMAIL PROTECTED] wrote:
> Due to request to change the name of algorithm.
> Relates to the thread 'new stream cipher'.
> AESC-Alex Ernst Stream Cipher.
I have just wrote a follow-up to the other thread. You may like to
answer it here.
M. K. Shen
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random Appearance
Date: Mon, 24 Jul 2000 23:24:12 +0200
Future Beacon wrote:
> I believe that it is possible. Winograd, at least 20 years ago, at
> MIT programmed a computer to form English sentences that were not
> predictable by the human correspondent. He had to understand
> grammar and logic very formally and well to do it. This kind of
> thing is covered in the subject of artificial reasoning. These
> kinds of achievements prompted me to try to form arbitrary English
> sentences from a string of random numbers. I am convinced that it
> is possible.
>
> If that is possible, then one could used whatever kind of encryption
> you like and take the resultant cipher text and convert it to a
> sequence of plausible English sentences (they may not make sense
> together, or they could with greater effort).
>
> Compactness is could actually be better than one-to-one if you limit
> vocabulary in certain ways. It requires many things - not the least
> of which is a spelling dictionary that is sorted by grammatical
> function and that numbers the words and is shared by the sender and
> receiver.
To let a computer to generate natural language sentences or even
music using random numbers is certainly possible. But the whole
set of random numbers used is not what you may intendedly
choose, or else the bunch of sentences would not fit together to
appear to belong to a natural discourse. That's the problem. To
transform a single sentence from a finite set of pre-determined
sentences to a natural sentence is never a problem.
M. K. Shen
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Q: Cascading multiple block algorithms
Date: Mon, 24 Jul 2000 14:29:33 -0700
That's correct, chosen-plaintext attacks are generally quite difficult to
come by. In times of war they're done through active means(e.g. break in,
plugin
your date, grab the output and leave). This is a very expensive type of
attack to carry out, but is considered mostly out of completeness, and
because it can very often uncover flaws that are of use for other attacks.
Joe
------------------------------
From: "The Gorf" <[EMAIL PROTECTED]>
Subject: School question for you regulars.
Date: Mon, 24 Jul 2000 14:38:06 -0700
I hope this is acceptable to post, but if I offend I apologize in advance.
I am eager to start my Coolege career but am unsure of what direction to go.
I am very interested in Computer Science, but I fear that while I will build
strong programming skills, I might not gain the solid math I want. On the
other hand if I go Mathemtaics I may lose programming skills. My desire is
to do signal analysis/processing, cryptanalys, and similar fields. I
realize this will take much math and software skills. But I am not sure
again as to which is the best course of action. If any of you guys out
there would care to share some of your wisdom I would greatly appreciate it.
I have been reading this group for a bit and must say that the content
always excites me even though I can only just understand what is going on.
Thanks again!
Geoff
------------------------------
Subject: Re: PGP US Versions Broken,no good??
From: Simon Johnson <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp
Date: Mon, 24 Jul 2000 14:36:17 -0700
YES!, You hit the nail on the head.
I think the analogy of a letter and an envelope is the best to
describe why we need cryptography.....
We put a letter in an envelope, so that person that delivers it
cannot get at the documents inside. The deliver can subvert this
protection, by ripping open the mail, then replacing the
envelope.
The point is, this tiny amount of protection, prevents this
from happening 99.9% of the time.
Using a stupidly-hard-to-break algorithm, such as twofish and
RC6, stops that same 99.9% of people trying to break the
encryption. That core of 0.1% can never be stopped, if they
can't break the encryption, they'll use other tactics to
retrieve the information in that 'envelope'.
I use encryption to prevent people, usally network
administrators, peeking at my files.
I can use something as crap as XOR, they have no idea how to
break it, and its fast as hell. They or forced into one of three
options:
1.) Delete File
2.) Leave File
3.) Break encryption
I personally rely on the administrators greatest weakness; there
lasy as hell ;). As i result, they don't even consider doing
option 3.
At home i use PGP, not because someone in my house is an expert
cryptanalyst, rather that my machine is open to the internet. If
someone else gets into my machine, some how, a PGP disk will
hold them back from my most sensative data.
Like i say, cryptographic needs depend on what u want to achieve.
===========================================================
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Practical application of Ciphersaber (Was: RC4-- repetition length?)
Date: 24 Jul 2000 21:53:42 GMT
In <8lgtl3$[EMAIL PROTECTED]> [EMAIL PROTECTED] (Guy Macon) writes:
]Scott Fluhrer wrote:
]>
]>Guy Macon <[EMAIL PROTECTED]> wrote in message
]>I also hope you are not going to design a real-life system based on what a
]>couple of guys on sci.crypt said, but you will check it out, right?
]No. Consider two childs dolls talking to each other through an
]infrared link. I want to make it more difficult for a hacker to
]be able to control the doll anmd make it say something that would
]be out of character. Not a big deal if it's cracked, but even a
]little security will weed out some attackers.
I would think that RC4 is not a good system for this. It has no
synchronising properties. Thus, the two ends (the two dolls) have to
know exactly where in the stream they are. A secret key block crypto system
would be much more usefull in this case I would think.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: RC4-- repetition length?
Date: 24 Jul 2000 22:02:51 GMT
In <e$hEvrS9$GA.318@cpmsnbbsa07> "Joseph Ashwood" <[EMAIL PROTECTED]> writes:
>Actually, it is difficult (if not impossible) to prove but
>it is quite intuitive that once you can distinguish
>something like RC4 from random it can be broken, whether or
>not the algorithm is known to us is a matter far removed
>from it's existance. My statements about how much data to
Any crypto with a finite key is by definition distinguishable from
random. (The algorithm and key give you every single byte in the
sequence.) Can you use that information to break it? Well, maybe, but I
doubt it. Crypto is all about how one uses the information, not that
that the information exists. The use of the deviations of RC4 from
random to break it may be an exponenetially hard problem. If it is (
and I do not know that it is), then I am completely willing to let
anyone gather as much statistical data as they desire.
Ie, in crypto the discussion is never a discussion of "in principle" but
one of "in practice".
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and sci.crypt) via:
Internet: [EMAIL PROTECTED]
End of Cryptography-Digest Digest
******************************
