Cryptography-Digest Digest #321, Volume #14 Wed, 9 May 01 13:13:00 EDT
Contents:
Re: Best encrypting algoritme (Mark Wooding)
Re: Optimizing AES throughput ("Brian Gladman")
Re: enumerating permutations ("Henrick Hellstr�m")
Re: Best encrypting algoritme ("Henrick Hellstr�m")
Re: Best encrypting algoritme (Mark Wooding)
Re: The novel _enigma_ by Robert Harris ("Robert Reynard")
Language information ("Brett W")
Are Boschloos creatures of GOD? (Fight Boschloo)
Re: Language information (Shaun Roe)
Re: Optimizing AES throughput (Harshal Chhaya)
Re: Best, Strongest Algorithm ("Joseph Ashwood")
Re: Best encrypting algoritme (SCOTT19U.ZIP_GUY)
Re: RSA BRUTE FORCE ("Joseph Ashwood")
Re: Cryptanalysis Question: Determing The Algorithm? (Bo D�mstedt)
Re: ECC question (Mike Rosing)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best encrypting algoritme
Date: 9 May 2001 10:12:58 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> Given a block cipher (the decision to use such a one is mostly
> 'fixed'), I believe that chaining is always a worthwhile additional
> operation to be done, because it is fairly cheap computationally in
> comparison to its benefit. However, I personally would prefer
> non-linear chainings to the linear ones like CBC.
Yes, some sort of chaining mode is necessary. ECB is clearly inadequate.
However, I don't see the point of nonlinear chaining. We have a
security proof which quantifies the strength of a block cipher in CBC
mode (using a real-or-random security model) relative to the difficulty
of distingishing the block cipher from a random function. This result
is extremely satisfactory.
Perhaps you can explain (a) how a nonlinear chaining mode will improve
the security bounds achieved by CBC already, and (b) why it's worth the
performance hit to do anything more complicated.
-- [mdw]
------------------------------
From: "Brian Gladman" <[EMAIL PROTECTED]>
Subject: Re: Optimizing AES throughput
Date: Wed, 9 May 2001 09:05:01 +0100
"Harshal Chhaya" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> Hello,
>
> The Rijndael document mentions a throughput of 70 Mbps on a 200 MHz
> Pentium Pro. This was using Brian Gladman's implementation in C.
>
> BTW, thanks Brian for the code.
Thank you for your comment.
> I would assume that an optimized assembly implementation might result
> in higher throughput. Am I correct here?
Yes. In particular some processors have special features that are not
normally used by C compliers but can give good speed increases in assembler.
For example, Helger Lipmaa has an assembler version of Rijndael that uses
the Pentium family MMX instructions to achieve a substantial speed increase
(1.8 vs 2.6 cycles per bit).
For straight assembler on the Pentium family (i.e. that does not rely on
such features) assembler will typically produce a speed increease of 10% to
20% this is hardly worthwhile on high end processors given the cost in terms
of lost applications portability.
Assembler comes into its own on low end systems (e,g, smartcards) where
constraints on both processor performance and memory make its use hard to
avoid. But its a lot more costly. C code can be used in many applications
so the value in terms of return on development time is very high. In
contrast assembler implementations each cost a lot more to develop while the
extent of their application is much more limited.
As usual its horses for courses.
Brian Gladman
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: enumerating permutations
Date: Wed, 9 May 2001 13:39:40 +0200
"wtshaw" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> While some say that you need to solve to learn some crypto, even be the
> first to crack something, deriving information from lesser scraps is
> promising and probably means that you have a good shot at actually
> producing new and useful ideas. Keep it up in spite of how bad you get or
> deserve to be panned when you make a false start.
I assume that there was some implication in there somewhere pointing in my
direction. That point was taken long ago, but is unfortunately not fully
implemented yet. Have a look at http://www.streamsec.com/howto.asp
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: "Henrick Hellstr�m" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Wed, 9 May 2001 13:52:04 +0200
"Mark Wooding" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]...
> Perhaps you can explain (a) how a nonlinear chaining mode will improve
> the security bounds achieved by CBC already, and (b) why it's worth the
> performance hit to do anything more complicated.
Have a look at http://csrc.nist.gov/encryption/modes/proposedmodes/
--
Henrick Hellstr�m [EMAIL PROTECTED]
StreamSec HB http://www.streamsec.com
------------------------------
From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Best encrypting algoritme
Date: 9 May 2001 12:29:35 GMT
Henrick Hellstr�m <[EMAIL PROTECTED]> wrote:
> "Mark Wooding" <[EMAIL PROTECTED]> skrev i meddelandet
> news:[EMAIL PROTECTED]...
> > Perhaps you can explain (a) how a nonlinear chaining mode will improve
> > the security bounds achieved by CBC already, and (b) why it's worth the
> > performance hit to do anything more complicated.
>
> Have a look at http://csrc.nist.gov/encryption/modes/proposedmodes/
I've seen some of them. The advantages they provide are increased
parallelism, authentication, or both. But they don't tend to provide
better security as symmetric ciphers.
Many of the more interesting ones also have patents attached, which I
think will disqualify them from particularly wide acceptance.
-- [mdw]
------------------------------
From: "Robert Reynard" <[EMAIL PROTECTED]>
Subject: Re: The novel _enigma_ by Robert Harris
Date: Wed, 9 May 2001 09:52:27 -0400
"Ed Pugh" <[EMAIL PROTECTED]> wrote in message
news:9da8dm$7ir$[EMAIL PROTECTED]...
> Well, I figured that. Not being privy to knowledge about operations
> at BP, there are probably several inconsistencies in the novel, but
> I don't have the knowledge to pick up on those.
Another 'error' was the railway stops mentioned for the train. It seems
Harris used a current train schedule and there were one or two stations on
that schedule that did not exist in the time frame of the novel.
BTW, if you want to read a book about codebreaking during WWII that has
excellent detail about the activities at BP, get a copy of 'Battle of Wits -
The Complete Story of Codebreaking in World War II' by Stephen Budiansky.
ISBN 0-684-85932-7.
It is, by far, the best book on the subject. Budiansky really gets it right.
It is a factual history, not a romantic novel, so he doesn't mention train
stations, 'hums' and 'glows,' silver planes or knots per hour.
An extremely nice aspect of Budiansky's book is the detail that is
available, but whose understanding is not required to enjoy reading the
book. A very skillful combination of overall codebreaking activity and how
it related to the conduct of the war with technical cryptanalysis at a level
of detail that would probably enable the reader to build and operate some of
the cipher machines of that period.
------------------------------
From: "Brett W" <[EMAIL PROTECTED]>
Subject: Language information
Date: Thu, 10 May 2001 00:03:37 +1000
Hi
I'm doing a project on cryptanalysis on languages other than English. I'm
considering comparing cryptanalysis techniques on simple ciphers in several
different languages, one of them, a constructed language of my own. I'm
additionally interested in investigating crypto attacks based more on the
structure of the plaintext's language than letter frequency analysis.
I've scoured the web using google, but couldn't seem to find much that can
help me. I'd like to look at frequency analysis and the measurement of
redundancy in a language. Are there tables of letter frequencies for
languages such as French, Latin and Japanese? Also, how does one compute the
redundancy of a language?
If anyone has any information regarding this, or any pointers on the
project, I'd like to hear from you.
Thanks in advance,
BrettW
------------------------------
Date: 9 May 2001 01:08:51 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: Are Boschloos creatures of GOD?
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
Just wondering
------------------------------
From: Shaun Roe <[EMAIL PROTECTED]>
Subject: Re: Language information
Date: Wed, 09 May 2001 17:31:03 +0200
For this kind of generic information about languages, try looking at the
work which has been done on the voynich manuscript, compring it with various
language 'signatures'
shaun
in article 9dbinj$vj7$[EMAIL PROTECTED], Brett W at [EMAIL PROTECTED]
wrote on 5/9/01 4:03 PM:
> Hi
>
> I'm doing a project on cryptanalysis on languages other than English. I'm
> considering comparing cryptanalysis techniques on simple ciphers in several
> different languages, one of them, a constructed language of my own. I'm
> additionally interested in investigating crypto attacks based more on the
> structure of the plaintext's language than letter frequency analysis.
>
> I've scoured the web using google, but couldn't seem to find much that can
> help me. I'd like to look at frequency analysis and the measurement of
> redundancy in a language. Are there tables of letter frequencies for
> languages such as French, Latin and Japanese? Also, how does one compute the
> redundancy of a language?
>
> If anyone has any information regarding this, or any pointers on the
> project, I'd like to hear from you.
>
> Thanks in advance,
>
> BrettW
>
>
------------------------------
From: [EMAIL PROTECTED] (Harshal Chhaya)
Subject: Re: Optimizing AES throughput
Date: Wed, 09 May 2001 16:05:32 GMT
On Tue, 08 May 2001 20:53:07 GMT, "Tom St Denis"
>No offense.... but USE A BLOODY SEARCH ENGINE.
None taken. I had RTFM'ed before asking here. Your suggested query on
Yahoo shows only the NIST page. A similar query on Google results in
more matches but none of them have the info I am looking for.
Brian, thanks for confirming what may have been obvious to some. Even
though I won't be using Intel processors, the basic principles still
apply.
I guess I should have given some background. I am trying to find the
suitability (not in crypto terms) of AES in a communications network.
At high data rates, it seems like the encryption, if done in s/w,
could be a bottleneck. The 70 Mbps figure (on a 200MHz PPro) in the
Rijndael paper looked good till I started extrapolating it to
communication processors running at lower speeds. A h/w implementation
is the best option but I was hoping that a s/w solution might suffice
till the h/w is done.
Thanks for your replies.
Regards,
Harshal
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Best, Strongest Algorithm
Date: Tue, 8 May 2001 11:53:14 -0700
"SCOTT19U.ZIP_GUY" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Actually when it comes to crypto [in the United States] the NSA has the
final word.
That is to some degree correct. They are in a position to exert undue force
on the decision. However the simple fact that the selection of Rijndael was
well-founded in the original goals of the AES selection process, and that
all the finalists were asked barring their own submission which should win,
they all (except the Rijndael team of course) agreed that Rijndael was the
preferred choice. So while the NSA may have had the final word, that word
coincided with the publicly ascertained desires of the contestants
themselves, some of the finest cryptanalysts in the world.
> [EMAIL PROTECTED] (Joseph Ashwood) wrote in <envXT2m0AHA.274@cpmsnbbsa07>:
[snip I said something about Rijndael]
> The ciphers the NSA uses for the government are not open for
> us to view. There is no reason to believe that Rijndael is any
> where close to the secret ciphers the NSA uses.
You'd be surprised how open they actually are. Not blatantly so, but we do
have knowledge of key sizes, number of instructions, block sizes, cipher
type, and sometimes knowledge of ancestry. Additionally we can gain more
information by looking at the devices they purchase from the private sector
for exactly these purposes. So no I don't know exactly what each cipher the
government uses looks like, but I have a general idea that Rijndael is
decent company for them, and quite likely their equal. The only concern that
remains is the statement by Coppersmith during the AES process, stating that
MARS was designed to protect against still classified forms of attack,
attacks the other authors have no (public) knowledge of. I believe in the
next few years this situation will change. We already have evidence that the
public cryptanalytic activities are closing on the secret, and we have
evidence that the attack on SKIPJACK was unknown to them, and that ECC took
them by surprise. These indicate to me that the public knowledge is lacking
mostly small portions of knowledge; bits and pieces from classified books,
and the design of the current ciphers.
> Rijndael will
> only be implimented in modes the NSA can safely break.
There is no evidence of that, and significant evidence to the contrary.
Strictly speaking if you believe that Timmermans BICOM is a secure
implementation of Rijndael then by your judgement there is an implementation
of Rijndael in a secure mode, which violates your initial statement.
> If it was
> otherwise the NSA has failed its main job. And that is to keep
> tabs on everything.
No the NSA's primary purpose is to protect our information, secondarily they
keep tabs on the critical information used by other governments, and to use
this to assist the other agencies.
>
> >
> >You have in front of you a machine that can do certainly no more than 2
> >billion additions per second. Let's say that it only takes one addition
> >to encrypt with Rijndael (which it doesn't it actually takes much more),
> >that means that 32-bit crypto can be broken in 2 seconds, 64-bit in 8
> >billion seconds. But even with 1 billion billion of these machine
> >working 24 hours a day it would take 20,000 years to break 128-bit
> >cryptography. To break 256-bit cryptography with 1 billiob billion
> >billion billion of those machines would take 400,000,000 years. I don't
> >believe the short key is a major issue.
> >
>
> Again you use the approach that the NSA are fools.
No I use the approach that whether or not the NSA chose Rijndael it was the
preferred choice of the finalists, so it should have won. From there I
extend to we don't know any attacks better than brute force against
Rijndael, so brute force is the most reasonable method of attack, and the
values for a brute force attack were given.
> Even versions of
> the Naval Engima had far more then 256 bit key.
But they had flaws, we do not know of any usable flaws in Rijndael.
> Hell by your defination
> a ceaser cipher of the ascii character set is safe since the number
> of keys 256! much much longer than your punny AES of 256 bits.
Completely incorrect. First a Ceasar cipher operates on text only, this
limitted it to 24 possible encipherments (Latin has 24 characters, not 26),
your statement shows that you do not understand what a true ceasar cipher
is. Second both a Ceasar cipher, and the Substitution cipher that you have
mistaken for a Ceasar have significant flaws. Again I repeat Rijndael has no
known attacks better than brute force.
> The point is be limiting it to 256 bits you limit the complexity
> of the resultion encryption.
No by limiting to 256 bits, the selection of permutations is limited to a
set of size 2^256. This has nothing to do with the "complexity" of the
encryption. Measuring the actual security has nothing to do with the speed
of encipherment/decipherment, at least not where slower is necessarily
better. Proving that is quite easy, would Rijndael be stronger encryption is
I inserted a "wait one minute" between each round? No it would not,
therefore speed of encryption/decryption is not of great import. It is worth
noting that optimal speed of decryption does place a lower bound on the
speed attack (otherwise the attack would be a more optimal decryptor). The
complexity of the encryption algorithm has little to do with the actual
strength. I should have to point only to the OTP to prove this, it is the
simplest encryption algorithm I know of, but it is provably unbreakable.
> However that said I think one can foil the NSA by at least not
> using weak modes and by using fully bijective versions of Rijndael
> such as Matts BICOM.
Earlier you said "Rijndael will only be implimented in modes the NSA can
safely break" please feel free to correct whichever one you believe to be in
error.
> Instead of versions that will help the NSA
> breaking system. One should never have a sytem where is possible that
> one key is the only one that works. In Matts system at least all of
> the keys point to a potinally file.
And prove to me why use BICOM provides a situation where more than one key
will produce a sensible decryption. That proof will be very hard, if not
impossible, without breaking Rijndael in which case you'll have something
much better to publish.
> The NSA wants to be able to
> read all encrypted messages.
I doubt that the NSA doesn't have the man power to read all the messages,
they will have to filter them somehow. Otherwise they would have to employ
at least 50% of the world, since that would be 6 times the population of the
US, I doubt they employ that many. So they must only want to read message
that are of interest to them
> It may also help law encforcement with drugs.
I think I can think of someone better to help with his drugs.
> IN short the NSA has to much power.
The NSA has very little power, the NSA you imagine (which can be completely
debunked) has very little relation to reality.
> I prefer a free people that don't need a
> big brother watching our every step.
I think you need someone to watch your every step, wouldn't want you to have
another bad trip.
Joe
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Best encrypting algoritme
Date: 9 May 2001 15:55:32 GMT
[EMAIL PROTECTED] (John A. Malley) wrote in
<[EMAIL PROTECTED]>:
>
>
>wtshaw wrote:
>[snip]
>>
>> An encryption algorithm is essentially a whole. Chaining modes are
>> not the only nor the best ways to add strength. As I said elsewhere,
>> it is true that the chaining mode must be solved together with what
>> other steps are involved, but these modes can be trivial complications
>> in the scheme of things. It would be better to not need them by
>> selecting a better single algorithm.
>
>That's an interesting suggestion - but can we do without chaining modes
>for block cipher algorithms? Isn't every block cipher used in ECB mode
>(the same as without any chaining modes) vulnerable to block replay?
>Given enough known plaintext-ciphertext pairs won't a cryptanalyst begin
>to construct a "code-book" to aid further ciphertext analysis? And
>won't statistics of the plaintext show through (albeit only as can be
>discerned in terms of the occurrences of block-size chunks)? Even the
>very best (however that's defined) block cipher used in ECB mode has
>these drawbacks.
>
>An All-Or-Nothing Transformation acting on the entire message is
>probably an example of a better single algorithm. Otherwise, there's
>good reason to use a block chaining mode with a block cipher.
>
You don't need really to use anything better than ECB mode to create
a cipher program that effectively hides all cipher text block pairs.
from an attacker. There are many wasy to do it. Suppouse program
ENC only works on full blocks of data so the input and output
files and in whole block length units.
Step 1 optional
compress bijectively to binary files
Step 2 convert to FOF file
Step 3 convert to file of N bytes per field
Step 4 run ENC on full blocks
Step 5 convert of FOF file
Step 6 convert to byte file
Step 7 uncompress like h2unc.exe or simalar
Step 8 reverse file end for end
Step 9 recompress to binary file with bijective file compressor
Step 10 convert to FOF file
Step 11 convert to file of N bytes per field
Step 12 run ENC on full blocks differnt password best
Step 13 convert to FOF file
Step 14 convert to binary file
Many of the above step can be combined. Example
in my condtional compressors most compress to FOF files.
The above type of scheme does a "all or nothing" transform
and does not allow the attack to collect possible pairs
for the input and output of each block. It will
also encrypt any file biejctively so that any key would
decrypt any file such that when encrypted you get the same
output back.
Example of combining use
BICOM with key1
then use h2unc.exe
reverse file
use BICOM with key2
That does essentially same thing as 14 steps above, And
effective double key space while lengthing the
blocksize to that of the whole file. Puls totally
bijective any file can be thought of as input file
or output file.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL 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 or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: RSA BRUTE FORCE
Date: Tue, 8 May 2001 15:04:32 -0700
That's been there for a while. I can't remember right now which algorithm it
is (it was used a year ago in a demo in france on breaking an RSA key). The
thing is that "close" here is in the magnitude, so 3 and 5 are as "close" as
2^1000+3 and 2^1000+5. By being exponential in the distance between them it
the extra bits in the primes actually take care of this for us. On average 2
512-bit numbers will have a "distance" of 2^511 between them, being
exponential in that is very bad. It's not something I'd lose sleep over,
picking "close" primes (for some usable value of close) is actually rarer
than picking a 128-bit number correct on the first try, so I personally
wouldn't even worry about it, don't bother changing your generation schemes.
Joe
"Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Joseph Ashwood wrote:
> > ... I found that for values that are close together this
> > works fairly quickly, but as the numbers get further apart the time
grows
> > exponentially ...
>
> Hm, does that mean we have yet another constraint to add when
> picking primes for RSA: Don't pick them too close together?
------------------------------
From: [EMAIL PROTECTED] (Bo D�mstedt)
Subject: Re: Cryptanalysis Question: Determing The Algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Wed, 09 May 2001 15:50:50 GMT
Douglas A. Gwyn wrote:
> ? No actual system can come close to implementing the general
> mapping table (for reasonable N).
The algorithm space is much larger than the key space.
This could make the recovery of the algorithm proportionally
harder, compared to ordinary plaintext/cipher key cryptanalysis,
right ?
> Anyway, one does not search across all possible mappings in a
> brute-force manner.
Shure.
When you have discovered a structural property of the target
cipher, you may reduce the search space. If you cannot discover
any structural properties, you must continue searching for these
properties.
> Almost all actual systems have structural regularities, and uncovering
> these is the first task in cryptodiagnosis.
Right. But mostly not very easy...exept for small ciphers,
like the simple substitution cipher, rotor machines, hand ciphers,
etc.
> > The problem for the cryptographer, is to prevent the structure
> > of the cipher to become known, if a cipher machine would fall
> > into the hands of the enemy (Kerckhoffs principle). This may
> > be accomplished using both cryptographic and implementation
> > techniques and methods.
>
> That's like saying the problem is to keep the enemy from
> discovering the plaintext. It's the ultimate goal, but
> in practice it is often not realized.
I was referring to the cipher algorithm. You may keep a secret
cipher algorithm from falling into the hands of the enemy by using
"cryptographic and implementation techniques and methods".
> I don't know; I thought the contrast between trying assumptions
> sequentially and in parallel was clear to begin with.
It is.
You still assume that the set of cipher algorithms is equivalent to
the set of published cipher algorithms (everyone else reading
has already figured this out, right ??)
Bo D�mstedt
Chief Cryptographer
Protego Information AB
http://www.protego.se
------------------------------
From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: ECC question
Date: Wed, 09 May 2001 11:46:54 -0500
Tom St Denis wrote:
> Ack my brain exploded!!!!
:-)
> BTW why is it called the "j" invariant?
I don't really know, but I can guess. The first person to publish anything
on it used the letter j and said it equalled a certain formula and that this
was interesting because it was an invariant. Since it's been called that for
over 200 years, you'd confuse a lot of people calling it anything else :-)
Patience, persistence, truth,
Dr. mike
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
