Cryptography-Digest Digest #489, Volume #13 Thu, 18 Jan 01 15:13:01 EST
Contents:
Re: using AES finalists in series? (Mok-Kong Shen)
Re: An arithmetic curiousity ? (Bob Silverman)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: Any good source of cryptanalysis source code (C/C++)? (Bob Silverman)
Re: using AES finalists in series? (Roger Schlafly)
Re: Differential Analysis (Kenneth Almquist)
Re: A Small Challnge (Bryan Olson)
Re: using AES finalists in series? (Terry Ritter)
Re: block algorithm on variable length without padding? (Terry Ritter)
Re: using AES finalists in series? ("Paul Pires")
Re: using AES finalists in series? (Terry Ritter)
Re: using AES finalists in series? ("Gary Watson")
----------------------------------------------------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 19:09:29 +0100
Gary Watson wrote:
>
> If one had sufficient CPU power or minimal throughput requirements, is there
> any reason why one couldn't use all five AES round two finalists in series?
> This would guard against a weakness being found in one of them, or if one or
> two of the candidates were deliberately weak systems promulgated by sinister
> government forces. (Is it necessarily true that security must improve at
> least a little each time you run the ciphertext through a new crypto
> algorithm? Don't know, this isn't my line of work...)
>
> As a side note, if a government or large company implements its crypto in an
> FPGA, why not distribute the entire FPGA design as the keying material? It
> fits in a $5 serial prom the size of your fingernail; it's loaded once and
> then the keying material is removed and possibly destroyed. You could have
> a room full of semi-trained people generating variants of the chosen cipher
> and re-running the synthesis tools, or maybe automate the process using a
> bit of clever VHDL such as multiple architectures per entity in each major
> functional block, and the architectures would be selected randomly before
> synthesis.
The topic has been discussed previously. The disadvantage
of not using a standard is non-conformity (conformity is
the very purpose of standardization). The disadvantage
of using multiple encryptions (different or same algorithms
in series) is mainly loss of efficiency. But, for fixed
communication partners, where conformity can be achieved
through appropriate arrangements and where lower efficiency
is acceptable, one could in my humble opinion well use
variants of algorithms (e.g. more rounds) and multiple
encryption, provided one is not very careless in doing so.
(But maybe you would soon see flames to my repetition of
heretical opinions.)
M. K. Shen
=========================
http://home.t-online.de/home/mok-kong.shen
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: An arithmetic curiousity ?
Date: Thu, 18 Jan 2001 18:43:32 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Charles Nicol) wrote:
> Is it true that Sigma(phi(n))=n-1 iff n=2^k,k>=1,where sigma is the
sum of
> the divisors and phi is the Euler(totient) function of n?
Not so subtle hint:
1 + 2 + 4 + ... + 2^k = 2^(k+1) - 1.
The proof is trivial
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Thu, 18 Jan 2001 18:46:47 GMT
In article <94077c$blqps$[EMAIL PROTECTED]>,
"Haider Ali" <[EMAIL PROTECTED]> wrote:
> Hi.....
>
> I am looking for any good cryptanalytic attacks on block ciphers,
programmed
> in C/C++ (I need the source code).....
Why? Not, "why do you need to know the attacks", but rather,
"why do you need source code?"
And you fail to specify which block cipher.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Thu, 18 Jan 2001 18:49:26 GMT
In article <9413j4$7iu$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Tom,
>
> When will you learn not to reply to posts if you aren't willing to
help.
> This kind of answer is wasting people's time.
WRONG. Tom's answer was 100% on target. IMO, the QUESTION was a
waste of time.
You can't learn anything about the subject by looking at code
and TANSA as a general "block cipher decryption algorithm".
Each algorithm will be specific to the cipher.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Thu, 18 Jan 2001 18:59:50 GMT
In article <941cbd$drt$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Maybe the answer could be a little bit less rude and point the person
> into the right direction. I thought this was a place where people
could
> ask questions and get help.
Yes, it is. But people asking questions are expected to do at least a
little basic reading first. The question was so off the wall that it
is clear the poser had not looked into the subject himself.
People who reply here are not a cure for laziness.
>Just because some people here spent their
> whole time working on crypto related matters doesn't mean they don't
> have the right to be treated with respect.
I think you mean "don't spend their whole time".
You went from one extreme to the other. People don't have to
be experts, but they should be expected to do a little homework
first.
>
> The man in question might not have as much time to search the web as
> you. Why re-invent the wheel when some people already know the
answer.
Why should we take the time to answer a question from someone who
hasn't done any homework first? It is OUR time. If we are
going to donate some time to answer questions, we have a right to
expect that those asking questions have done at least SOME reading
on the subject. If they are interested in the answer, they should
be willing to spend some time on it.
A
> simple answer with a few links and no rudeness would be enough.
>
> If one doesn't want to help, then they shouldn't but it doesn't mean
> they should put other people down or even insult them.
Noone was put down or insulted. And while I agree that noone should
be put down or insulted for not knowing something, I think they SHOULD
be put down for being unwilling to spend any time themselves.
> Funny how some
> educated and knowledgeable people can have so little manners.
Funny how some people think that they should have a right to have their
question answered by an expert while being unwilling or too lazy to
do some basic reading first.
It is bad manners to expect someone else to do your work for you.
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Bob Silverman <[EMAIL PROTECTED]>
Subject: Re: Any good source of cryptanalysis source code (C/C++)?
Date: Thu, 18 Jan 2001 19:03:03 GMT
In article <941u8s$tj3$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
>
> > Brice, you are correct in the general case but Tom has a point in
this
> > special case. The rules of the forum expect mewbies to read the
FAQ.
> > It seems clear that the question to which Tom responded was posted
by
> > a newbie looking for magic.
>
> I can understand that. However, i think the rudeness of the reply by
Tom
> was un-necessary
I don't think Tom was rude at all. I think the original poster
was rude to ask others to waste time answering a question which
could have been answered with a couple of minutes work with a search
engine.
You sound like "I want what I want when I want it and anyone who
tells me otherwise is rude".
--
Bob Silverman
"You can lead a horse's ass to knowledge, but you can't make him think"
Sent via Deja.com
http://www.deja.com/
------------------------------
From: Roger Schlafly <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 11:16:49 -0800
Gary Watson wrote:
> If one had sufficient CPU power or minimal throughput requirements, is there
> any reason why one couldn't use all five AES round two finalists in series?
> This would guard against a weakness being found in one of them, or if one or
> two of the candidates were deliberately weak systems promulgated by sinister
> government forces. (Is it necessarily true that security must improve at
> least a little each time you run the ciphertext through a new crypto
> algorithm? Don't know, this isn't my line of work...)
> As a side note, if a government or large company implements its crypto in an
> FPGA, why not distribute the entire FPGA design as the keying material? It
> fits in a $5 serial prom the size of your fingernail; it's loaded once and
> then the keying material is removed and possibly destroyed. You could have
> a room full of semi-trained people generating variants of the chosen cipher
> and re-running the synthesis tools, or maybe automate the process using a
> bit of clever VHDL such as multiple architectures per entity in each major
> functional block, and the architectures would be selected randomly before
> synthesis.
Sure, you can do all those things if you want. But your ideas are
directly contrary to the idea of a standard. The point of AES is
to have one cipher that is efficient and secure for a lot of
people to use and interoperate. It is not to encourage people to
roll their own crypto because they don't trust the AES design.
------------------------------
From: [EMAIL PROTECTED] (Kenneth Almquist)
Subject: Re: Differential Analysis
Date: 18 Jan 2001 19:21:30 GMT
> Hmm. What I've been doing for finding XOR pairs is this:
> for (x = 0; x < 256; ++x) {
> table[256] = { 0 };
> for (y = 0; y < 256; ++y)
> ++table[sbox[x]^sbox[x^y]];
++table[sbox[y]^sbox[x^y]];
> for (z = !x; z < 256; ++z) {
> if( table[z] <= 4 ) continue;
> fprintf(f,"%02x->%02x ",x,z);
> fprintf(f,"(%d/256)\n",table[z]); }
> }
>
> Is this correct or incorrect?
It is incorrect. For each possible value of x and z, you are counting
the number of values of y such that:
sbox[y] ^ sbox[y ^ x] = z
Therefore, when you the expression sbox[x] in your code, you know that
you made a mistake.
Kenneth Almquist
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Crossposted-To: sci.math,comp.theory
Subject: Re: A Small Challnge
Date: Thu, 18 Jan 2001 19:18:47 GMT
rosi wrote:
> Bryan Olson wrote in part ...
>
| | The fact that this obviously useless modification satisfies
> >the requirements leads me to believe that either the
> >requirements left out something important, or there just isn't
> >much to this notion.
>
> Correct. Again randomization is not QP otherwise QP embraces
> some very uninteresting things.
I don't think you understood. My modification (to any PK
cipher) required no randomness.
The question is whether the notion adds one interesting thing.
If so, what?
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 19:43:52 GMT
On Thu, 18 Jan 2001 19:09:29 +0100, in
<[EMAIL PROTECTED]>, in sci.crypt Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
>Gary Watson wrote:
>>
>> If one had sufficient CPU power or minimal throughput requirements, is there
>> any reason why one couldn't use all five AES round two finalists in series?
>> This would guard against a weakness being found in one of them, or if one or
>> two of the candidates were deliberately weak systems promulgated by sinister
>> government forces. (Is it necessarily true that security must improve at
>> least a little each time you run the ciphertext through a new crypto
>> algorithm? Don't know, this isn't my line of work...)
>>
>> As a side note, if a government or large company implements its crypto in an
>> FPGA, why not distribute the entire FPGA design as the keying material? It
>> fits in a $5 serial prom the size of your fingernail; it's loaded once and
>> then the keying material is removed and possibly destroyed. You could have
>> a room full of semi-trained people generating variants of the chosen cipher
>> and re-running the synthesis tools, or maybe automate the process using a
>> bit of clever VHDL such as multiple architectures per entity in each major
>> functional block, and the architectures would be selected randomly before
>> synthesis.
>
>The topic has been discussed previously. The disadvantage
>of not using a standard is non-conformity (conformity is
>the very purpose of standardization).
As discussed previously (see, for example:
http://www.io.com/~ritter/NEWS4/LIMCRYPT.HTM
), that argument is poor.
Cryptography is *fundamentally* a non-conformity. We *deliberately*
build cipher systems so that information is obscured unless both sides
achieve agreement with the correct keys. So, while the *idea* of keys
is a standard, having nonstandard key values is at the core of
cryptography.
How do we deal with a nonstandard? We introduce some way to define
the unknown: Typically, we deliver keys in a secure way (e.g., a
public key layer).
But in the same way we now deliver keys, there is ample opportunity to
describe a particular cipher, or a multiple ciphering sequence of
ciphers. One might even deliver the actual code for a new cipher.
Banks want a government-approved cipher, which they use for legal
liability reasons. For most other cases, each individual cipher is
what it is, and each cipher is a standard of one. There is remarkably
little advantage, and great disadvantage, in having just a single
cipher to use.
Real security would do better with a meta-standard, negotiating cipher
selection and multi-ciphering structure (as well as key values), in a
way conceptually similar to modems negotiating speeds. Negotiation
need not be real-time.
>The disadvantage
>of using multiple encryptions (different or same algorithms
>in series) is mainly loss of efficiency. But, for fixed
>communication partners,
Nonsense. The advantages are not limited to "fixed communication
partners."
>where conformity can be achieved
>through appropriate arrangements and where lower efficiency
>is acceptable, one could in my humble opinion well use
>variants of algorithms (e.g. more rounds)
It is not true that giving a cipher more rounds makes it necessarily
stronger. For one thing, surely no cipher can be stronger than its'
keyspace.
In contrast, multiple ciphering expands the keyspace, and also
protects each individual cipher against known-plaintext attack, which
is a very serious advantage.
>and multiple
>encryption, provided one is not very careless in doing so.
>(But maybe you would soon see flames to my repetition of
>heretical opinions.)
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: block algorithm on variable length without padding?
Date: Thu, 18 Jan 2001 19:47:12 GMT
On 18 Jan 2001 16:20:03 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (DJohn37050) wrote:
>You can also use ciphertext stealing from the previous block to fill out the
>last block. This is no weaker than CBC. The trick comes in deciphering, you
>need to handle the last partial block and previous full block appropriately,
>but this is not hard to figure out.
Unless, of course, there *is* no previous block. Then there is no
ciphertext to steal.
It is unreasonable, in a general cipher implementation, to refuse to
cipher or fail just because the message is short.
It does seem odd that texts oriented toward computer implementation do
not treat this case.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Paul Pires" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 11:50:50 -0800
Gary Watson <[EMAIL PROTECTED]> wrote in message
news:nuF96.1804$wL5.36733@NewsReader...
>
> If one had sufficient CPU power or minimal throughput requirements, is there
> any reason why one couldn't use all five AES round two finalists in series?
> This would guard against a weakness being found in one of them, or if one or
> two of the candidates were deliberately weak systems promulgated by sinister
> government forces. (Is it necessarily true that security must improve at
> least a little each time you run the ciphertext through a new crypto
> algorithm? Don't know, this isn't my line of work...)
Not binary answers here but something to think about...
Is the security of a process only reduced when important elements
are omitted? Can a flaw be introduced by adding operations?
I believe this has been demonstrated in some cases. So,
how are you going to get any confidence in your process to justify
the added complexity? How are you going to maintain the confidence
in the components you use that are being used under different
conditions than they were analyzed?
Can you randomly mix chemicals and achieve a non-toxic
result?
Sure.
Should you test them by ingestion?
Paul
====== Posted via Newsfeeds.Com, Uncensored Usenet News ======
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
======= Over 80,000 Newsgroups = 16 Different Servers! ======
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 20:00:39 GMT
On Thu, 18 Jan 2001 11:16:49 -0800, in
<[EMAIL PROTECTED]>, in sci.crypt Roger Schlafly
<[EMAIL PROTECTED]> wrote:
>Gary Watson wrote:
>> If one had sufficient CPU power or minimal throughput requirements, is there
>> any reason why one couldn't use all five AES round two finalists in series?
>> This would guard against a weakness being found in one of them, or if one or
>> two of the candidates were deliberately weak systems promulgated by sinister
>> government forces. (Is it necessarily true that security must improve at
>> least a little each time you run the ciphertext through a new crypto
>> algorithm? Don't know, this isn't my line of work...)
>> As a side note, if a government or large company implements its crypto in an
>> FPGA, why not distribute the entire FPGA design as the keying material? It
>> fits in a $5 serial prom the size of your fingernail; it's loaded once and
>> then the keying material is removed and possibly destroyed. You could have
>> a room full of semi-trained people generating variants of the chosen cipher
>> and re-running the synthesis tools, or maybe automate the process using a
>> bit of clever VHDL such as multiple architectures per entity in each major
>> functional block, and the architectures would be selected randomly before
>> synthesis.
>
>Sure, you can do all those things if you want. But your ideas are
>directly contrary to the idea of a standard. The point of AES is
>to have one cipher that is efficient and secure for a lot of
>people to use and interoperate. It is not to encourage people to
>roll their own crypto because they don't trust the AES design.
Wrong. The point of AES is to have a government-approved cipher so
banks need not worry about legal liability.
"Interoperation" is precisely what we design ciphers to not do.
Ciphers specifically do not interoperate without correct keys. But if
we can deliver correct keys, we can also deliver the correct cipher --
or perhaps just a description of what the correct cipher should be.
AES is of course an attempt to limit cipher development, and
especially to limit the profits available to continue cipher
development.
A widely-used standard cipher is the best possible target for real
cryptanalysis. By breaking only one cipher, one exposes a fount of
information, and nobody will know -- or can afford to believe -- that
has happened. Absent unarguable proof of strength, embracing any
single cipher puts real security at risk.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Gary Watson" <[EMAIL PROTECTED]>
Subject: Re: using AES finalists in series?
Date: Thu, 18 Jan 2001 20:01:29 -0000
"Roger Schlafly" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Gary Watson wrote:
> > If one had sufficient CPU power or minimal throughput requirements, is
there
> > any reason why one couldn't use all five AES round two finalists in
series?
> > This would guard against a weakness being found in one of them, or if
one or
> > two of the candidates were deliberately weak systems promulgated by
sinister
> > government forces. (Is it necessarily true that security must improve
at
> > least a little each time you run the ciphertext through a new crypto
> > algorithm? Don't know, this isn't my line of work...)
> > As a side note, if a government or large company implements its crypto
in an
> > FPGA, why not distribute the entire FPGA design as the keying material?
It
> > fits in a $5 serial prom the size of your fingernail; it's loaded once
and
> > then the keying material is removed and possibly destroyed. You could
have
> > a room full of semi-trained people generating variants of the chosen
cipher
> > and re-running the synthesis tools, or maybe automate the process using
a
> > bit of clever VHDL such as multiple architectures per entity in each
major
> > functional block, and the architectures would be selected randomly
before
> > synthesis.
>
> Sure, you can do all those things if you want. But your ideas are
> directly contrary to the idea of a standard. The point of AES is
> to have one cipher that is efficient and secure for a lot of
> people to use and interoperate. It is not to encourage people to
> roll their own crypto because they don't trust the AES design.
Your point is well taken; I believe in standards. The options are not
mutually exclusive, however. One device or software package could simply
offer an option to superencipher with the other AES candidates to enhance
"diversity" (for lack of a better word).
The purpose of a crypto standard IMHO is more than interoperability with the
world at large. Another purpose is to have a convenient, tested, strong,
robust system for people to use in their own proprietary applications. If I
made up a crypto system of my own, it would be subject to my lack of skill
in cryptography. On the other hand, if I use five recent-vintage algorithms
which have convenient NSA-generated and -validated VHDL source code
available, and put them in series, it makes up for my personal weaknesses
and substitutes the combined talents of the best in public cryptography,
with virtually no effort or royalty payments on my part.
I don't have a specific application for any of this in mind. What I am
thinking about are the public policy implications of having these five VHDL
packages on a system which is available for anyone in the world to download.
I'm just trying to assess how this could impact intelligence gathering in
the future. If I were to embed a crypto system into something of my own
design, I'd probably stick to Rijndael and be done with it. After all, Mr
I.B. Pomposity III, your typical CEO, is going to use his wife's birthday as
the input key anyway.
--
Gary Watson
[EMAIL PROTECTED] (you should leave off the digit two for email)
Nexsan Technologies Ltd.
Derby DE21 7BF ENGLAND
UK-based Engineers: See our job postings at
http://www.nexsan.com/pages/careers.htm
------------------------------
** 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
******************************
