Cryptography-Digest Digest #588, Volume #10 Thu, 18 Nov 99 20:13:03 EST
Contents:
Re: AES cyphers leak information like sieves (Tim Tyler)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: What part of 'You need the key to know' don't you people get? (wtshaw)
Re: Simpson's Paradox and Quantum Entanglement ("karl malbrain")
Re: Known attacks on AES candidates? (David Crick)
Re: Simpson's Paradox and Quantum Entanglement ("Tony T. Warnock")
Evaluation of Enigma as a Design Springboard (wtshaw)
Re: Group English 1-1 all file compressor (William Rowden)
Re: "The Code Book" challenge update (Angus Walker)
Re: Simpson's Paradox and Quantum Entanglement ("karl malbrain")
Re: Simpson's Paradox and Quantum Entanglement (John Savard)
Letter Frequency in English Texts vs. Name Lists ([EMAIL PROTECTED])
Letter Frequency in English Texts vs. Name Lists ([EMAIL PROTECTED])
Re: AES cyphers leak information like sieves ("Peter K. Boucher")
----------------------------------------------------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Thu, 18 Nov 1999 20:05:52 GMT
Jerry Coffin <[EMAIL PROTECTED]> wrote:
: In article <80tfml$tg6$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
:> Even Bruce had the balls in his book to say the the error correction
:> should be handled in the transmission protocals. Hell even in the
:> Navy they don't require radio operators to use morse code any more
:> it is going to secure digital communications. But maybe that is over
:> your head.
: Morse code or otherwise isn't the question. If you have the luxury of
: being able to verify each block and re-transmit as needed, then yes,
: that's almost certainly better than depending upon recoverability of
: errors using CBC. [...]
Variable-size blocks allow you to set the block size equal to the
message size. This produces the super-scrambling that you think is such
a problem over noisy lines.
However there's nothing stopping you reducing the block size and using
good old-block chaining, if you *really* want it.
The point is that the cases where you want it are now rare and they
occur very infrequently over (say) the internet.
Thus it doesn't make sense to force error recovery (and the security
issues that result from today's implementations of it) on those who don't
need it.
I'm not certain, but I have difficulty in imagining a "chaining mode"
of a block cypher that produces very much diffusion of information
between blocks. If using a fixed size, small block block cypher, you
should probably applu diffusion to your message first.
:> >Those who really believe that simply re-transmitting a message is
:> >reasonable if it doesn't come through intact should read _Between Silk
:> >and Cyanide_ continuously until they learn better.
:>
:> Bullshit.
: I see your vocabulary remains as lacking in eloquence as ever. If you
: honestly believe that nobody's life will ever be placed in danger
: again, or something like that, you're simply an idiot.
Perhaps you two are having communications problems here.
Retransmitting encrypted messages is a perfectly reasonable method of
dealing with failed communications. This is true even if a few blocks
have dropped out of a message and need to be resent - the best method is
often to retransmit the entire original cyphertext again.
Failure to deliver a message can be important - but if you need your
message to get through you can usually send a super-secure transmission
with plenty of redundancy and error correction.
You can sent the same message by three different routes - *if* its
arrival is important and you're prepared to pay the price of higher
interception chances.
Hell, if it's really important, *and* there's no chance to retransmit it,
*and* the channel is really noisy, *and* the bandwidth is so limited you
can apply little error correction, *and* getting some of the message
though is better than nothing at all, *and* you're prepared to reduce the
security of the message's encryption with that goal in mind, you can
*always* reduce the blocksize, chain a few blocks encrypted with the same
key together - and use the system just like an ordinary block cypher ;-)
--
__________
|im |yler The Mandala Centre http://www.mandala.co.uk/ [EMAIL PROTECTED]
I only open my mouth to change feet.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 18 Nov 1999 14:51:10 -0600
In article <810qrg$jg0$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>
> Assuming 26 pins per wheel you need 28 wheels to match a 128-bit key.
> Did they have 28 wheels? I am not sure... did they?
>
Should be 83.68 bits x 28 = 2343.04, not that it matters.
--
For those looking for security in Windoze, sorry, you're SOL.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 18 Nov 1999 14:26:40 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
> It seems to me that a block chaining mode that diffuses information from
> the plaintext throughout the cyphertext will generally cause the analyst
> more problems.
Proportionately. But, there are two aspects of the cipher to be
considered: One, that a small number of blocks needs to be considered to
break the cipher anyway, and that a proportionate marginal increase is
strength may still produce weak encryption.
According to the SSS#, marginally strong encipherment requires that at
least something like 3500 bits of message be recovered to verify the keys
as true. That goal is something I define as reasonable, given a viable
alternative.
--
For those looking for security in Windoze, sorry, you're SOL.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 18 Nov 1999 14:34:20 -0600
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> Jerry Coffin wrote:
> > In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> > [ talking about CBC (for one example) ]
> > > Do you think that he is not correct, and that the information is,
> > > in fact, distributed through the message?
> > Of course not -- if a single error corrupted the entire message, you'd
> > lose one of the major advantages of CBC.
>
> The plaintext information *is* distributed through the remainder
> of the ciphertext. The reason one can recover after an error is
> that the *original* ciphertext remains available past the point
> of the error. But that ciphertext depends on all previous
> plaintext.
While avalanching can increase effective security, to say that it is
essential in a means is to confuse its real cause/effect relationship
since no avalanching is necessary to achieve good security in all
algorithms, not forgetting that almost all of those that lack it are
vulnerable because of their structure; the exceptions are important to
look for.
--
For those looking for security in Windoze, sorry, you're SOL.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Thu, 18 Nov 1999 14:47:22 -0600
In article <810qrg$jg0$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
>
> Assuming 26 pins per wheel you need 28 wheels to match a 128-bit key.
> Did they have 28 wheels? I am not sure... did they?
>
Let's see about that: With 25 permuted output possibilities, an N of 26,
that represents 88.38 bits per wheel. For a given number of wheels,
multiply.
28 x 88.38 bits = 2474.64 bits. But, if someone finds a 28-wheel enigma,
or that number of historic wired options, please contact NSA with the
details. ( I figure they would like to know about it.)
--
For those looking for security in Windoze, sorry, you're SOL.
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Thu, 18 Nov 1999 12:46:05 -0800
<[EMAIL PROTECTED]> wrote in message news:81119m$o43$[EMAIL PROTECTED]...
> Simpson's Paradox:
> http://curriculum.qed.qld.gov.au/kla/eda/sim_par.htm
>
> Simpson's Paradox is a statistical artifact related to
> hidden variables. Here it in terms of quantum entanglement.
Simpson's description of VINGH as a SUBJECTIVE/OBJECTIVE problem -- WHO is
trying to change ownership of WHAT property for their SINGULAR benefit.
HISTORY is a MAJORITY subject.
> Given that
>
> 1) A and B are complementary
> 2) A and B are both true XOR A and B are both false
>
> then, that 1) contradicts 2) is the essence of Simpson's Paradox.
No, you are only describing a SINGULARITY by ignoring (or hiding) the
SUBJECTIVE/OBJECTIVE contradiction.
> We can make an arbitrary determination that "A is True"
> to resolve that paradox, but this choice is arbitrary as we could
> equally have chosen to make the determination that
> "B is True". Regardless of the choice we can then instantly
> determine the complementary variables state as "anti-correlated".
There are NO arbitrary DETERMINATIONS. Each is a SUBJECTIVE choice unique
to the INDIVIDUAL's HISTORY.
> Similarly, in entanglement the arbitrary measurement of
> a polarization or spin state will instantly (non-locally)
> determine the state of the anti-correlated entangled twin.
You are only trying to prove that THINGS don't CHANGE -- trying to get
something for nothing. Karl M
------------------------------
From: David Crick <[EMAIL PROTECTED]>
Subject: Re: Known attacks on AES candidates?
Date: Thu, 18 Nov 1999 20:48:32 +0000
[EMAIL PROTECTED] wrote:
>
> I have been studing the AES candidates and want to summarize know the
> attacks.
Well done for this - it's something I've been meaning to do myself.
> Mars -- Equivalent keys for non AES key lengths.
I could swear that I have heard/read of other crypto attacks on
MARS (and I'm not talking the power-related ones here).
Unfortunately I can't remember where or provide any kind of
reference, so take that as you may.
The complexity of MARS, together with it's DDR-related performance
(and possible weaknesses, see the RC6 attack), and it's poor
performance on "future" architectures (Merced/Itanium), make me
less enthusiastic about MARS in general though.
> RC6 -- Equivalent keys for non AES key lengths. Not totally random up
> to 15 rounds. Differential weakness in reduced round versions.
>
> TwoFish -- Whitening keys are not equally distributed.
>
> Serpent -- ??
>
> Rijndael -- ??
Only your own observations. The authors go through the "Sqaure Attack"
in the specs, and seem to give it enough safety margin.
> Any other know weakness? I am especially interested in papers on
> Rijndael or Serpent.
>
> RC6 seems to be the only one with a serious problem at this point.
>
> BTW, papers are available for all of the above in the 'Cipher Block
> Lounge.'
I'd also suggest checking the NIST AES discussion forums.
David.
--
+-------------------------------------------------------------------+
| David Crick [EMAIL PROTECTED] http://members.tripod.com/vidcad/ |
| Damon Hill WC96 Tribute: http://www.geocities.com/MotorCity/4236/ |
| M. Brundle Quotes: http://members.tripod.com/~vidcad/martin_b.htm |
| ICQ#: 46605825 PGP Public Keys: RSA 0x22D5C7A9 DH/DSS 0xBE63D7C7 |
+-------------------------------------------------------------------+
------------------------------
From: "Tony T. Warnock" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Thu, 18 Nov 1999 14:00:09 -0700
Reply-To: [EMAIL PROTECTED]
Simpson's paradox has nothing to do with quantum mechanics. It's just an
artifact of using multiple comparisons. It has occurred in baseball.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Evaluation of Enigma as a Design Springboard
Date: Thu, 18 Nov 1999 15:29:54 -0600
The limitations of Enigma are due in part to limitations of production and
dated technology. Consider that there is no reason to have so limited a
number of wheels as was the case in WWII; the many wheel wiring
possibities can be easily simulated on a computer, which could combine
also the plugboard variations.
In another thread, I have commented on permutation possibilities which
might be included in an electronic design, but did not make it clear as to
my intent. Having to stay sit the actual historic design with its
limitations would be not be sufficent.
Surely, we would want to accept a maximum number of characters that would
be allowed without completely revising the wheels, not just reseting
them.
The physical design problem caused by the loop back through the wheels
that forces a character to never represent itself can be solved through
not doing that, in short, using a single pass through the rotors, no
reflector.
Some stupidity in operator use and official procedures can also be easily
handle by a smart application that limits certain protocol abuses. But,
the human element seems to be forever a source of problems.
The Enigma seems fixable, but there are seemingly radically different
designs that are more promising.
--
For those looking for security in Windoze, sorry, you're SOL.
------------------------------
From: William Rowden <[EMAIL PROTECTED]>
Subject: Re: Group English 1-1 all file compressor
Date: Thu, 18 Nov 1999 21:20:28 GMT
I may have missed discussion on another thread that would make a
difference in my understanding of your proposal. Nevertheless, here are
my thoughts:
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
> However, if you allow multiple passes, the problem vanishes ;-)
Doesn't the problem also vanish if one of the encoding rules is to
encode the longest possible substring? You can implement this as a
finite-state machine.
> It doesn't seem to matter much which order you compress in for this
> example: both schemes reduce the original 16 letters to 7.
If you do this using the rule I suggest above, at once rather than in
multiple passes, your examples aren't two alternative schemes; they are
two different ways of expressing the same approach. In fact, if one
switches "#" and "@" in your second scheme's dictionaries, the encoding
is identical, too.
> Finding dictionaries that compress as well as is possible (with this
> multiple pass scheme) will not be easy.
If you want a compressor (that is not adaptive?) for a source model that
is some type of English, then there is a wealth of frequency information
available.
> Can anyone present an argument about whether compressing short or
> long substrings first is the better strategy?
One argument is algorithm availability. An algorithm for finding the
longest substrings using a finite-state machine is well-known and
implemented in regular expression searching.
In article <80vkaf$1uks$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:
> Thank You for the info I can see there is a lot of work to do if
> people want to make this a go. I may write a test one using a few of
> there to see if it compresss much smallers
You're welcome.
It doesn't look like a lot of work to write a test compressor. My
Unix/Linux bias is about to show: If you know 'awk' (which uses regular
expressions), you could write a short script. Another alternative is
'lex', which has the benefit of providing you with C source code.
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Angus Walker <[EMAIL PROTECTED]>
Subject: Re: "The Code Book" challenge update
Date: Thu, 18 Nov 1999 22:12:31 +0000
Any hints for stage 3?
--
Angus Walker
------------------------------
Reply-To: "karl malbrain" <[EMAIL PROTECTED]>
From: "karl malbrain" <[EMAIL PROTECTED]>
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Thu, 18 Nov 1999 14:27:59 -0800
Tony T. Warnock <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Simpson's paradox has nothing to do with quantum mechanics. It's just an
> artifact of using multiple comparisons. It has occurred in baseball.
You are just as bad as the original poster. Logically, EVERYTHING has
SOMETHING to do with REALITY. Most people need help sorting out LIES from
FICTION, or SUBJECTS from OBJECTS. It's a question of how much of the
problem you're prepared and willing to deal with -- you can't just DECREE it
away. Karl M
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: comp.ai.fuzzy,sci.physics,sci.math
Subject: Re: Simpson's Paradox and Quantum Entanglement
Date: Thu, 18 Nov 1999 22:51:40 GMT
[EMAIL PROTECTED] wrote, in part:
>Given that
> 1) A and B are complementary
> 2) A and B are both true XOR A and B are both false
>then, that 1) contradicts 2) is the essence of Simpson's Paradox.
>We can make an arbitrary determination that "A is True"
>to resolve that paradox, but this choice is arbitrary as we could
>equally have chosen to make the determination that
>"B is True". Regardless of the choice we can then instantly
>determine the complementary variables state as "anti-correlated".
Given (1) and (2), A is not true, and A is not false.
Since (1) and (2) have caused A and B to be self-referential
statements, the law of the excluded middle no longer applies to them.
This is like the "liar paradox": either A and B are lacking in
concrete meaning, or the "givens" are themselves false. You are
missing whatever part it has that makes it really paradoxical, if any.
Quantum-mechanically, a particle can have a state such that "A has
spin up" is neither true nor false, but subject to a probability
distribution. But once A is observed, if B is observed later, B may
have its own probability distribution, or it may correlate with A in
some fashion. But it can't, after observation, be both spin up and
spin down, either.
John Savard (don't snooze, don't snore)
http://www.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED]
Subject: Letter Frequency in English Texts vs. Name Lists
Date: Thu, 18 Nov 1999 22:54:51 GMT
I am doing research on large sets of name lists.
I have information on letter frequencies in
common english texts, but I am curious as to how
this compares to the letter frequencies in a
large name set.
Does anyone have a program that will calculate
letter frequency patterns when given a text data
file that they can share with me? Or even common
letter frequencies for name sets?
If you can help please e-mail me at
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Letter Frequency in English Texts vs. Name Lists
Date: Thu, 18 Nov 1999 22:54:52 GMT
I am doing research on large sets of name lists.
I have information on letter frequencies in
common english texts, but I am curious as to how
this compares to the letter frequencies in a
large name set.
Does anyone have a program that will calculate
letter frequency patterns when given a text data
file that they can share with me? Or even common
letter frequencies for name sets?
If you can help please e-mail me at
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
Date: Thu, 18 Nov 1999 16:07:08 -0700
From: "Peter K. Boucher" <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Tim Tyler wrote:
[snip]
> No. You're confusing data with information. The *data* changes in the
> /almost/ the manner which you are describing.
>
> [In fact you're wrong - at least you are if we are still discussing CBC
> block chaining with a single pass. In this instance all the data
> "upstream" from the file change remains unchanged.]
We were discussing CBC, reverse the bytes, then CBC again.
> However, the *information* in the plaintext is **not** distributed through
> the entire file.
Sure it is. You are confusing the question of whether information in
the plaintext is distributed (which it obviously is, if each ciphertext
bit depends on each plaintext bit), with the question of whether
information needed for decryption is distributed.
The first question has a bearing on your "pirate map" scenario. If
every ciphertext bit depends on every plaintext bit, there can be no
pattern in the data for an analyst to find.
> This means /all/ the information necessary to reveover a block of
> plaintext is present in the corresponding block of cyphertext, plus
> one more block upstream from it. From this it should be clear that
> information does not diffuse throughout the file, but remains in
> narrowly-defined blocks.
Wrong. Information from the plaintext does indeed diffuse throughout
the file, even though the information needed to decrypt is found in two
(or in this case, three) blocks.
> David's comments were correct.
David's comments were based on an ignorance of the basic concepts of
cryptography.
> : If each plaintext bit has an effect on each ciphertext bit, then info is
> : [XXX] spread all through the file.
>
> No, this is false.
Think it through again.
> : It's as plain as the nose on your face. Your failure to understand
> : basic concepts of crypto bodes ill for the quality of your product.
>
> Alas, your insults would be more effective if your facts were straight ;-|
1) My facts were straight.
2) I'm not the one calling people f**king idiots (perhaps you'd like to
talk with Mr. Scott about the insults).
3) You need to do a little reading. Start with Schneier's book.
Regards,
Peter
------------------------------
** 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
******************************
