Cryptography-Digest Digest #319, Volume #14 Wed, 9 May 01 02:13:01 EDT
Contents:
Re: The novel _enigma_ by Robert Harris (Ed Pugh)
Re: Intacta.Code ... (newbie)
Re: Intacta.Code ... (newbie)
Re: The novel _enigma_ by Robert Harris (John Savard)
keen bitsliced idea cipher ("Tom St Denis")
Re: Tiny s-boxes ("Brian McKeever")
Re: Back to the Drawing Board (John Savard)
Re: Tiny s-boxes ("Tom St Denis")
Re: A Question Regarding Backdoors (wtshaw)
Re: Best encrypting algoritme (wtshaw)
Re: enumerating permutations (wtshaw)
Re: Bleaming strock cipher ("Scott Fluhrer")
Re: Best encrypting algoritme ("John A. Malley")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Ed Pugh)
Subject: Re: The novel _enigma_ by Robert Harris
Date: 9 May 2001 02:01:26 GMT
Reply-To: [EMAIL PROTECTED] (Ed Pugh)
Thanks for your follow-up, Robert.
"Robert Reynard" ([EMAIL PROTECTED]) wrote:
> "Ed Pugh" <[EMAIL PROTECTED]> wrote in message
> news:9d9pq4$eh5$[EMAIL PROTECTED]...
>> I just re-read (2nd time) Robert Harris' excellent novel,
>> _enigma_ (and, no, that is not a typo; the title name begins
>> with a lower-case 'e').
>
> That depends upon where you 'read' the title. On the 1st Edition by Random
> House, New York printed for the US market, the dustcover title was in lower
> case, but all upper case on the title page and in other places in the book.
> That was not the case for the 1st Edition printed by Hutchinson, London for
> the UK market nor the paperback. Titles were in upper case. As with most
> books, the dustcover (jacket) is designed by different artists for different
> printings.
Woops. You're right! I hadn't noticed that. I just copied the title
off of the dust jacket. Sorry about that.
>
>> I think, however, that there may be a few technical inaccuracies
>> in the novel.
>
> More than you realized. :-)
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.
>
>> Would Allied war planes have been silver by this time, or would
>> they have still been painted olive-green?
>
> I'm not an expert, but I believe that B-17s were initially unpainted metal
> (silver in appearance) and painted various ways to make them more difficult
> to see. The first operational B-17 flew in 1935, it was metallic. The
> undersides were often painted 'sky-blue.'
Actually, there is a thread right now in soc.history.war.world-war-ii
(or whatever it's called, exactly) about silver vs. olive-drab B-17s.
The consensus there seems to be that the EARLIER ones had the olive-drab,
and they decided later to use unpainted (silver) bombers. However,
I thought it might have been later in 1943 that they did that.
>> Also, I always thought that only jet engine planes would form
>> contrails. Would piston-prop driven airplanes form white
>> contrails in the sky?
>
> Contrails are condensed water vapor, caused by the temperature gradient. All
> you need is hot exhaust from an engine, jet or otherwise, and very cold air.
> B-17s flew at altitudes over 20,000, which makes for contrails. Again, I'm
> not an expert, but I think I have this correct.
OK, that makes sense. I've just never seen it, that's all.
>
>> "In his cubbyhole next to the captain's berth, the radioman
>> pressed his switches. The Enigma came on with a hum."
>
>
>> "The next ten letter pairs represented the cross-pluggings he
>> needed to make on the steckerboard on the back of the Enigma."
Again, I am unsure if Enigmas had an internal voltage transformer.
When you think about it, there is no reason why the current HAS to
be DC, but the voltage has to be small enough for the light bulbs
and to prevent switch and rotor contact arcing. Today, I revisited
a web site that had photo of an Enigma, and there were TWO sets of
power contact. One was labelled 4 volts (presumably DC) and the
other was labelled 220 volts (presumably AC), which suggests that
the Enigma had a voltage step-down transformer (which could "hum").
However, I still don't know if the U-boats would have had an AC
electrical system (220 Volts?) to power the Enigma.
[snip]
>
> I pointed out to the publisher (Random House Ltd) a small technical 'error,'
> which appears on page 70 of the printing you are referencing. The term
> 'knots per hour' was used when it should have read simply 'knots' (nautical
> miles per hour). I noticed that in the paperback printed about a year or so
> later, by Arrow, this slight error was corrected.
Yes, I had noticed that same error, but did not bother to mention it
as it was more a grammatical/semantic error rather than a technical
one. But you are right; assuming Lieutenant Cave was in the Navy,
he would not have said "seven knots per hour".
>
> Enigma is a fictional novel, of course, and some literary license is to be
> expected, not to mention that it is practically impossible to print anything
> that does not contain errors. It is especially difficult for the fictional
> novelist to get all the details correct, since it is unlikely that the
> writer personally experienced the entire narrative.
Even so, as you point out, I would have expected Harris to at least
get the details of the Enigma correct. I still cannot believe that
he had the Steckerboard on the BACK of the Enigma in the novel. At
least that one is pretty glaring.
Even with the technical faults, I still immensely enjoyed the novel
and am having a hard time waiting for the movie to make the rounds
here.
Best regards,
--
Ed Pugh, <[EMAIL PROTECTED]>
Ottawa (Richmond), Ontario, Canada
"Bum gall unwaith-hynny oedd, llefain pan ym ganed."
(I was wise once, when I was born I cried - Welsh proverb)
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ...
Date: Tue, 08 May 2001 22:22:17 -0300
????
What are you talking about???
Once you read what it was said before, then you have the right to
talk!!!!!!!
Tom attacked me
John Lebbs attacked me
And now you!!!!
You are wasting your time!!!!
Are you crazy???
Joseph Ashwood wrote:
>
> I have stayed out of this for a while, because you seemed to at least have
> the decency to only include Tom in your (honestly quite childish) attacks.
> However you have obviously decide that anyone who replies to you is
> inadequate. maybe you're compensating for some personal lacking? Let me
> guess you want a Corvette? that's just so perfectly Freudian. I suppose for
> once your attacks make you feel like a "big" man?
> Joe
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
------------------------------
From: newbie <[EMAIL PROTECTED]>
Subject: Re: Intacta.Code ...
Date: Tue, 08 May 2001 22:23:40 -0300
YOU HAVE TO LOOK FOR A PSYCHIATRIST!!
Joseph Ashwood wrote:
>
> I have stayed out of this for a while, because you seemed to at least have
> the decency to only include Tom in your (honestly quite childish) attacks.
> However you have obviously decide that anyone who replies to you is
> inadequate. maybe you're compensating for some personal lacking? Let me
> guess you want a Corvette? that's just so perfectly Freudian. I suppose for
> once your attacks make you feel like a "big" man?
> Joe
>
> "newbie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: The novel _enigma_ by Robert Harris
Date: Wed, 09 May 2001 02:40:34 GMT
On 9 May 2001 02:01:26 GMT, [EMAIL PROTECTED] (Ed Pugh) wrote,
in part:
>Again, I am unsure if Enigmas had an internal voltage transformer.
>When you think about it, there is no reason why the current HAS to
>be DC, but the voltage has to be small enough for the light bulbs
>and to prevent switch and rotor contact arcing.
Actually, you *want* a little bit of rotor contact arcing, otherwise a
film of oxidation or oil could develop that eventually prevents
contact from being made. However, the light bulbs are of the
flashlight type, and the Hebern rotor machine used only a few dry cell
batteries, so I think you are right, even though other rotor machines
did use a higher voltage to avoid contact problems.
Although the rotors are moved mechanically, I could imagine that an
electrical motor could still provide the power to move them, so that
the operator would not have to press quite so hard on the keys of the
Enigma as would be required to advance the rotor. That would certainly
hum. But I don't think that was done either.
Thus, the bit about the hum was probably put in thoughtlessly for
dramatic effect, I'm afraid.
Actually, though, you may have hit on the explanation: batteries are
expensive, and they need to be transported. So a transformer to allow
use of external power could well have been used with any Enigma that
might be used where a conventional source of power was available. Such
as would be required for a powerful radio transmitter.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: keen bitsliced idea cipher
Date: Wed, 09 May 2001 02:39:27 GMT
I know I know, I should analyze my own designs but I just want a "feel"
before I get serious on this design.
Features? Simple design, efficient on x86s (3.2 million blocks per second
or 48.72 megabytes/sec or 389.72 megabits/sec) also efficient in hardware
since it only uses trivial wiring, xor/and gates.
The design is based on Neokeon (sp?) cipher but with a better nonlinear
transform namely
a ^= b^(c&d);
b ^= c^(d&a);
c ^= d^(a&b);
d ^= a^(b&c);
Which is a 4x4 sbox with a dpmax of 4 and a lpmax bounded by +/- 4. The
inverse is trivial too ... it.s the same thing just going in the opposite
direction (clocked backwards). Unlike Neokeon the nonlinear transform is
not an involution however it is obvious that the same hardware can be used
by simply re-wiring the inputs i.e a <=> d and c <=> b.
The C source for the cipher is at http://tomstdenis.home.dhs.org/tc15.c
which is very simple to follow.
--
Tom St Denis
---
http://tomstdenis.home.dhs.org
------------------------------
Reply-To: "Brian McKeever" <[EMAIL PROTECTED]>
From: "Brian McKeever" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Wed, 09 May 2001 02:39:57 GMT
"Mark Wooding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Interestingly, small S-boxes are making something of a comeback in
> bitslice block ciphers. Noekeon, a new cipher by Daemen, Peeters, Van
> Assche and Rijmen and submitted to the NESSIE project, uses a single
> self-inverse 4x4 S-box.
This isn't the first time I've seen the term "bitslice", but I still don't
know what it means. Would you mind explaining it?
Thanks,
Brian
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Back to the Drawing Board
Date: Wed, 09 May 2001 02:44:59 GMT
On Wed, 09 May 2001 02:18:15 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>Many thanks for your explanations. A couple of questions:
>(1) I guess that for crypto purposes good error correction
>property is disadvantageous in general. Am I right? (So
>the above type of codes isn't bad for crypto after all.)
Even a poor error correction property is disadvantageous for removing
redundancy, but I don't propose to use these codes to transform
plaintext prior to encryption.
>(2) It seems that m is chosen to be at or in the close
>vicinity of n/2. Is that true?
Yes, as this leads to the maximum number of possible symbols in n bits
with a constant number of bits set to one.
>(3) From your experiences
>till present do you see certain directions where
>applications of such codes in crypto are (or could
>potentially be) profitable?
The main relevance I see of such a code is in connection with bit
swapping, as done in the block cipher ICE. If I want to mix two words
by swapping some bits in one word with the bits in corresponding
positions in the other word, the mixing is, in some sense, the most
thorough if I select exactly half the bits to swap.
And it gives me the excuse to throw in another S-box, and generally
provides increased nonlinearity as well.
John Savard
http://home.ecn.ab.ca/~jsavard/
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Tiny s-boxes
Date: Wed, 09 May 2001 02:49:59 GMT
"Brian McKeever" <[EMAIL PROTECTED]> wrote in message
news:162K6.1921$[EMAIL PROTECTED]...
> "Mark Wooding" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Interestingly, small S-boxes are making something of a comeback in
> > bitslice block ciphers. Noekeon, a new cipher by Daemen, Peeters, Van
> > Assche and Rijmen and submitted to the NESSIE project, uses a single
> > self-inverse 4x4 S-box.
>
> This isn't the first time I've seen the term "bitslice", but I still don't
> know what it means. Would you mind explaining it?
It means you break down the sbox into boolean logic. Then you can apply
multiple copies in parallel.
For example the 3x1 function
F(x,y,z) = x ^ (y&z)
Can be viewed a function on a 3 bits to 1 bit or possible 96 bits to 32
bits.
That is bit sliced operations.
Tom
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: A Question Regarding Backdoors
Date: Tue, 08 May 2001 20:26:49 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> Phil Carmody wrote:
> >
>
> > Can a sensible amount of nested 'crippled crypto' be used to emulate
> > 'strong crypto'?
> > e.g. one can turn DES into Triple-DES (though DES isn't exactly
> > crippled).
> [snip]
>
> I like to mention that this question is (at least in
> some sense) related to an issue described by wtshaw,
> which rests yet uncommented on. See my follow-up in the
> thread 'Cryptanalysis Question: Determing The Algorithm?'
> of 07 May 2001 12:25:01 +0200.
>
> M. K. Shen
It matters not that there might be a weakest link is a well nested
algorithm because all links need to be solved on their own merits.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Best encrypting algoritme
Date: Tue, 08 May 2001 20:33:02 -0600
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Mark
Wooding) wrote:
> wtshaw <[EMAIL PROTECTED]> wrote:
>
> > When Rijndael is combined with a chaining mode, it is no longer
> > Rijndael. To measure the strength of an algorithm means no window
> > dressing should be fudged into the process.
>
> But we know how to measure the strength of a chaining mode relative to
> the strength of the underlying block cipher. See, for example, `A
> Concrete Security Treatment of Symmetric Encryption: Analysis of the DES
> Modes of Operation', by Bellare, Desay, Jokipii and Rogaway.
>
> -- [mdw]
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.
--
Mother Nature always gets her revenge.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: enumerating permutations
Date: Tue, 08 May 2001 20:46:24 -0600
In article <Jb_J6.47269$[EMAIL PROTECTED]>, "Tom St
Denis" <[EMAIL PROTECTED]> wrote:
> "Henrick Hellstr�m" <[EMAIL PROTECTED]> wrote in message
> news:9d9qj2$nnd$[EMAIL PROTECTED]...
> > You just reinvented one of the elements of the SteakCipher key schedule.
> Cf
> > http://www.stremsec.com/combutil.pas
> >
> > I don't know if I was the first to actually use this algorithm in this
> way.
> > Probably not. A similar algorithm was described by Knuth.
>
> Keen.
>
> Tom
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.
--
Mother Nature always gets her revenge.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Bleaming strock cipher
Date: Tue, 8 May 2001 22:02:27 -0700
Paul Pires <[EMAIL PROTECTED]> wrote in message
news:hKXJ6.8753$[EMAIL PROTECTED]...
> The following is a cipher concept I have been working on.
> This material is very similar to the last concept I posted, the
> one that Scott Fluhrer and Brian Olson euthanized on contact.
> The idea is a stream cipher that processes it's output in large
> blocks. The goal is to have a cipher that is:
>
> 1, relatively simple.
> 2, very fast.
> 3, internally obscure, one that does not reveal it's internal state
> so easily for a chosen or known plaintext attack and one that
> is safe against bit-flipping.
>
> This cipher is simple (in code) and runs at 8.3 clocks per byte
> Note: No file I/O.
>
> The basic idea is to use two different sets of internal tables.
> One table, "A", is dynamically changing and its values are used
> only as location arguments for retriveing and storing values
> from the plaintext, ciphertext and the other table, "B". Both
> tables, A&B are split in two and handled seperately as A0,A1, B0,B1.
> Each cycle, the operations performed on these table halves
> alternate. Pointers are assigned to these table halves (A_old, A_new
> & B_old, B_new) and to alternate, the pointers are just re-assigned
> (swapped) for each cycle. So, here are the pieces:
>
> "A0" and "A1" together comprise table "A" and are 64 element tables, each
containing the
> values 0-63 initialized in a key dependent way. (unsigned char[75])
> Note: 11 bits from the front of the array are duplicated at the end.
>
> "B0" and "B1" together comprise table "B" and are each 64 element tables.
Each element is 32
> bits wide and are also initialized in a key dependent way. (unsigned
int[64]) .
>
> "A_new" and "A_old" are pointers that can be set and reset to the A
tables. (unsigned char*)
> "A_new_32" is a 32 bit wide pointer which is always set to the new "A"
address. (unsigned int*)
> "B_new" and "B_old" are pointers that can be set and reset to the B
tables. (unsigned int*)
>
> After every text block is processed (cycle) the pointers are re-set so
that what
> once was an old table becomes the new table and its values are then
updated,
> First "B" then "A". Cyphertext and plaintext are handled as 32-bit units
and
> are processed as blocks of the same length as a "B" table (64 elements).
>
> To process a block:
>
> Encrypt:
> for (i=0, i<64, i++)
> {
> C[A_old[A_new[i]]] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ P[i];
> }
>
> (Decrypt would be:
> P[i] = B_old[A_new[i]] ^ B_new[A_old[i]] ^ C[A_old[A_new[i]]] ;)
>
> Reset B pointers alternately. (odd is just the last bit of the cycle
counter "x")
>
> B_new = (odd) ? (unsigned int*) &B0 : (unsigned int*) &B1;
> B_old = (odd) ? (unsigned int*) &B1 : (unsigned int*) &B0;
>
> Update the Old (now named new) State B table. B1 in the case where the
> cycle count "x" is even:
>
> unsigned int wrapper = x ^ (B_new[0]<<27);
> for (i=0, j = 1, k = 63; i<63; i++, j++, k--)
> {
> B_new[i] = (B_new[i]>>5) ^ P[i] ^ C[A_new[k]] ^ (B_new[j]<<27);
> }
> B_new[63] = (B_new[63]>>5) ^ P[63] ^ C[A_new[0]] ^ wrapper;
>
> Now let's see if I've built another garage door and handed Pancho the
> remote opener.
Well, I hate to disappoint my fan club, so I'll start with this rather
surprising observation: after the first block, the parity of a plaintext
block and the parity of the corresponding ciphertext block is the same(!).
Here's how it works: lets call the parity of a plaintext block, B_new array,
B_old array and the ciphertext block P, B_new, B_old, C.
Case 1: Consider the case where B_new != B_old. Then, the encrypt process
will set C := B_old ^ B_new ^ P = !P. Then, it swaps B_new and B_old, and
then updates B_new := B_new ^ P ^ C = !B_new. Hence, it will handle the
next block as case 2, as B_new = B_old.
Case 2: Consider the case where B_new = B_old. Then, the encrypt process
will set C := B_old ^ B_new ^ P = P. Then, it swaps B_new and B_old, and
then updates B_new := B_new ^ P ^ C = B_new. Hence, in this case, C=P, and
in addition, it preserves the condition B_new = B_old, and hence it will
handle the next block as case 2.
Hence, after the first block, the cipher will stay in case 2, and so will
have P = C.
--
poncho
------------------------------
From: "John A. Malley" <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Tue, 08 May 2001 22:49:37 -0700
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.
John A. Malley
[EMAIL PROTECTED]
------------------------------
** 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
******************************
