Cryptography-Digest Digest #535, Volume #13 Tue, 23 Jan 01 22:13:01 EST
Contents:
Cryptographic Camouflage ("Joseph Ashwood")
Re: Some Enigma Questions (David Hamer)
Re: Dynamic Transposition Revisited (long) (William Hugh Murray)
Re: NSA and Linux Security (Shawn Willden)
Re: 32768-bit cryptography ("lemaymd")
In case you don't want to visit my website ("lemaymd")
Re: Some Enigma Questions -- 150*10^18 settings? (wint)
Re: collisions risks of applying MD5 or SHA1 to a 48-bit input ("JL")
Re: Dynamic Transposition Revisited (long) (AllanW)
Secure game highscore server ("Robert Larsen")
----------------------------------------------------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Cryptographic Camouflage
Date: Tue, 23 Jan 2001 16:10:13 -0800
A while back there was a discussion regarding cryptographic camouflage, at
the time there were some things that I couldn't say. Well I recieved notice
a bit ago that I can now say that you can find all the information at
http://www.delphion.com/details?pn=US06170058__ . I will avoid rendering any
personal opinions about it for the time being.
Joe
------------------------------
Date: Tue, 23 Jan 2001 19:16:05 -0500
From: David Hamer <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions
"Douglas A. Gwyn" wrote:
>
> "David C. Barber" wrote:
[snipped]
> > Q3: The plugs interchanged pairs of characters, hence there were two plugs
> > at each end. Were these plugs keyed to prevent improper insertation?
>
> No need to; they're symmetrical.
Actually they're not symmetrical...each stecker has two pins
at each end - 4mm. and 3mm. in diameter respectively - so
that they can only be inserted into corresponding socket on
the steckerboard in one way. The 'fat' pin at one end is
connected to the 'thin' one at the other thus acting as a
'crossover' for the signal.
David Hamer
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
David Hamer The Crypto Simulation Group
[EMAIL PROTECTED] or [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
From: William Hugh Murray <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 00:22:44 GMT
Terry Ritter wrote:
> On Tue, 23 Jan 2001 06:54:04 GMT, in
> <gU9b6.849$[EMAIL PROTECTED]>, in sci.crypt "Matt
> Timmermans" <[EMAIL PROTECTED]> wrote:
>
> >"Terry Ritter" <[EMAIL PROTECTED]> wrote in message
> >news:[EMAIL PROTECTED]...
> >> Essentially the problem is one of ambiguity: the idea that Kahn is
> >> talking about a real, practical OTP, when in fact he can only be
> >> talking about the theoretical OTP. For example, he starts out saying:
> >
> >Real practical OTP's do exist, and have been used to good effect.
I agree with Terry on this. It can be nearly practical or nearly provable but
not both.
------------------------------
From: Shawn Willden <[EMAIL PROTECTED]>
Subject: Re: NSA and Linux Security
Date: Tue, 23 Jan 2001 17:02:57 -0700
Greggy wrote:
> In article <[EMAIL PROTECTED]>,
> Shawn Willden <[EMAIL PROTECTED]> wrote:
> > And have the courts further upheld the application
> > of those powers, and noted that the reason for such
> > permissiveness is the ongoing state of emergency?
> The congress removed the issue from the jurisdiction of the US Supreme
> Court. We see this when they say, "This is a political matter" and
> deny a hearing. They are not allowed to hear the case and they say
> those words verbatim according to the law passed by congress.
Cites? You'll have to excuse me if I'm not willing to take your word for
it. Really, you should expect a great deal of skepticism, though, since
you're saying some rather surprising things. If what you're saying is
correct, however, you should be able to support it.
Shawn.
------------------------------
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: Re: 32768-bit cryptography
Date: Tue, 23 Jan 2001 18:56:49 -0600
Poncho,
From what you've written, it's looks as though simplicity is not this
cipher's weakness. What path would you suggest to strengthen it? I don't
truly understand how you would retrieve a completely random key (which of
course it's not, but for simplicity let's say it is) when you have only the
ciphertext. Theoretically, as is the case with the true stream cipher, one
XOR operation between the key and data should be sufficient to make an
entirely impossible to crack piece of ciphertext. Because of the huge size
of the key utilized by this algorithm, it almost qualifies as a stream
cipher itself. Thanks for your valuable input! : - )
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:94j39m$map$[EMAIL PROTECTED]...
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94i87e$d0e$[EMAIL PROTECTED]...
> > Poncho,
> > How does this algorithm look? Eight identical rounds are performed
on
> > each byte and each key value is rotated to the left one position after
> each
> > round.
> >
> > C[I] =
> >
>
(((((((((K1[I]^P[I])+K2[I])>>>K3[I])^K2[I])+K1[I])>>>K2[I])^K3[I])+K3[I])>>>
> > K1[I])
> >
> > K1, K2 and K3 are key derived values and the symbols use the conventions
> you
> > listed in your post.
> This looks almost as vulnerable to my attack. This attack is based on the
> following observations/assumptions:
>
> - In transforming N consecutive bytes of plaintext into ciphertext (that
is,
> 8*N bits), the transform can be fully described by specifying 8*N+11 bits
of
> internal keying data (based partially on how K1, K2, K3 are interrelated).
> The revised cipher increases that to 8*N+16 bits.
>
> - Given an arbitrary N byte plaintext section and N byte ciphertext
section,
> there are (at least reasonably often) approximately 2**11 values of the
> above internal keying data that transforms that plaintext to that
> ciphertext. This is the fishiest part of the attack, which is true if we
> model the actual cipher as a random function, which it is not. With the
> revised cipher, this increases to approximately 2**16 values, but this
> assumption also becomes rather more plausible.
>
> - Using dynamic programming, it is possible to explicitly derive the
> approximately 2**11 internal keying values corresponding to a particular
> plaintext/ciphertext pair. The revised cipher makes finding the values
> somewhat more expensive, but not prohibitively so.
>
> - Given a potential setting of internal keying data, we can check it by
> using it to decrypt the corresponding range of bytes in the ciphertext of
> other blocks, and seeing if it decrypts to plausible plaintext.
>
> - We can use "crib-dragging" to find plausible plaintext/ciphertext
> sequences.
>
> That should be enough for you to draw in the dots to get the full attack.
>
> >
> > In the rotation operations the 5 lsbits of the key values are used.
> Ummm, if we're talking about rotating 8 bit bytes, we need only specify 3
> bits
>
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > news:94b3hv$gda$[EMAIL PROTECTED]...
> > >
> > > lemaymd <[EMAIL PROTECTED]> wrote in message
> > > news:94aqn0$qrs$[EMAIL PROTECTED]...
> > > > To all interested:
> > > > Bermuda Triangle 2001 is an extremely fast, easy-to-use and
secure
> > > > cryptography engine. It is based on a new, 32768-bit algorithm of
the
> > > same
> > > > name. Algorithm details can be found at my site as well as a
software
> > > > product that uses the algorithm, Bermuda Triangle 2001 Golden
Edition.
> > I
> > > > also have a free cryptography engine that uses a similar (but
> > > incompatible)
> > > > algorithm available for download. Visit the site at:
> > > > http://www.bermudatriangle.f2s.com/
> > > > These software packages are written entirely in 32-bit, win32
assembly
> > > > language and I can encrypt or decrypt an 8.4MB file on my Pentium(R)
> 166
> > > in
> > > > 8 seconds. Please give me your feedback!
> > > This should be pretty easy to break given several encrypted blocks
with
> > > known plaintext (either several short messages encrypted with the same
> key
> > > or one long one). As I understand it, your encryption algorithm is
> > > essentially:
> > >
> > > C[i] = ((P[i] ^ x[i]) <<< y[i]) + z[i]
> > >
> > > where:
> > >
> > > P[i] is a byte of plaintext
> > > C[i] is a byte of ciphertext
> > > x[i], y[i], z[i] are key dependent values, and which are repeated
> every
> > > 4096 bytes (and are interrelated)
> > > ^ is xor, <<< is bitwise rotate, and + is addition mod 256
> > >
> > > Because x[i], y[i], z[i] repeat every 4096 bytes, this repetition
length
> > is
> > > called a block.
> > >
> > > Here's how to rederive a good portion of the keying data: for each
byte
> > > within a block, locate two plaintexts that differ in that byte by one
> bit.
> > > If you have at least 16 plaintexts, and the plaintexts are random, you
> > have
> > > a good chance of having such a pair. Then, examine the corresponding
> > > ciphertexts, and see the lsbit where they differ. The rotate that
moves
> > the
> > > plaintext bit that differs to that lsbit ciphertext bit that differs
> must
> > be
> > > correct, thus giving you the 3 lsbits of y[i]. A similar trick can
work
> > if
> > > you don't have a single pair that differs by precisely one bit, but
you
> > have
> > > several pairs with low-hamming weight difference.
> > >
> > > Once you have most of the y[i] values, you can use the
> interrelationships
> > to
> > > derive the 3 lsbits of x[i] and z[i]. Once you have that,
> reconstruction
> > > the rest of the x[i], z[i] values should be straight-forward.
> > >
> > > --
> > > poncho
> > >
> > >
> > >
> >
> >
>
>
------------------------------
From: "lemaymd" <[EMAIL PROTECTED]>
Subject: In case you don't want to visit my website
Date: Tue, 23 Jan 2001 19:03:56 -0600
In case you don't want to visit my website, here's the whole description of
the algorithm. Pay special attention to the area that talks about key
generation.
Also, I've heard a lot of great ideas on how to crack this cipher without
too much effort. Would anyone be willing to take up a challenge and try to
crack a 12-15K ciphertext message?
============================================================================
----
3. Description of algorithm
a. Encryption
Encryption using the Bermuda Triangle 2.0 algorithm consists of four simple
steps involving three key mutations. It operates with 32768-bit plaintext
and ciphertext blocks controlled by a 32768-bit key, referred to as K0. The
principal advantage of this algorithm is the requirement that the entire key
be known before any decipherment can take place. This is insured by two key
mutations, described here.
In the first mutation the entire key is loaded one byte at a time from the
end to the beginning and each subsequent byte is XORed against the previous
byte, in order of end to beginning. This information is then stored to
memory. Note: the last byte in this memory area will always equal the
original key data. This key is referred to as K1.
The second mutation performs the same operation in order of beginning to end
and the first byte is always equal to the original key data. This key is
referred to as K2. The original key is referred to as K3. These keys are
used later.
The actual encryption process involves eight rounds of nine
operations each. After each round the key values are rotated to the left by
one position. The identification tag described in section 2 is placed in
the first twelve bytes of this file
These steps are illustrated in this pseudocode:
C[I] =
(((((((((K2[I]^P[I])+K1[I])>>>K3[I])^K1[I])+K2[I])>>>K1[I])^K3[I])+K3[I])>>>
K2[I])
============================================================================
----
b. Decryption
Decryption is similar to encryption, with the operations simply being
performed in reverse and by substituting subtraction for addition and
rotation left for rotation right. The key mutations are identical and
interchangeable. Eight Rounds are performed with the key being rotated to
the right one position after each round. One rotation right is performed on
each key value before the rounds. The identification tag placed in the file
during encryption is discarded. The steps are detailed in this pseudocode:
P[I] =
(((((((((C[I]<<<K2[I])-K3[I])^K3[I])<<<K1[I])-K2[I])^K1[I])<<<K3[I])-K1[I])^
K2[I])
"Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
news:94j39m$map$[EMAIL PROTECTED]...
>
> lemaymd <[EMAIL PROTECTED]> wrote in message
> news:94i87e$d0e$[EMAIL PROTECTED]...
> > Poncho,
> > How does this algorithm look? Eight identical rounds are performed
on
> > each byte and each key value is rotated to the left one position after
> each
> > round.
> >
> > C[I] =
> >
>
(((((((((K1[I]^P[I])+K2[I])>>>K3[I])^K2[I])+K1[I])>>>K2[I])^K3[I])+K3[I])>>>
> > K1[I])
> >
> > K1, K2 and K3 are key derived values and the symbols use the conventions
> you
> > listed in your post.
> This looks almost as vulnerable to my attack. This attack is based on the
> following observations/assumptions:
>
> - In transforming N consecutive bytes of plaintext into ciphertext (that
is,
> 8*N bits), the transform can be fully described by specifying 8*N+11 bits
of
> internal keying data (based partially on how K1, K2, K3 are interrelated).
> The revised cipher increases that to 8*N+16 bits.
>
> - Given an arbitrary N byte plaintext section and N byte ciphertext
section,
> there are (at least reasonably often) approximately 2**11 values of the
> above internal keying data that transforms that plaintext to that
> ciphertext. This is the fishiest part of the attack, which is true if we
> model the actual cipher as a random function, which it is not. With the
> revised cipher, this increases to approximately 2**16 values, but this
> assumption also becomes rather more plausible.
>
> - Using dynamic programming, it is possible to explicitly derive the
> approximately 2**11 internal keying values corresponding to a particular
> plaintext/ciphertext pair. The revised cipher makes finding the values
> somewhat more expensive, but not prohibitively so.
>
> - Given a potential setting of internal keying data, we can check it by
> using it to decrypt the corresponding range of bytes in the ciphertext of
> other blocks, and seeing if it decrypts to plausible plaintext.
>
> - We can use "crib-dragging" to find plausible plaintext/ciphertext
> sequences.
>
> That should be enough for you to draw in the dots to get the full attack.
>
> >
> > In the rotation operations the 5 lsbits of the key values are used.
> Ummm, if we're talking about rotating 8 bit bytes, we need only specify 3
> bits
>
> >
> > "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> > news:94b3hv$gda$[EMAIL PROTECTED]...
> > >
> > > lemaymd <[EMAIL PROTECTED]> wrote in message
> > > news:94aqn0$qrs$[EMAIL PROTECTED]...
> > > > To all interested:
> > > > Bermuda Triangle 2001 is an extremely fast, easy-to-use and
secure
> > > > cryptography engine. It is based on a new, 32768-bit algorithm of
the
> > > same
> > > > name. Algorithm details can be found at my site as well as a
software
> > > > product that uses the algorithm, Bermuda Triangle 2001 Golden
Edition.
> > I
> > > > also have a free cryptography engine that uses a similar (but
> > > incompatible)
> > > > algorithm available for download. Visit the site at:
> > > > http://www.bermudatriangle.f2s.com/
> > > > These software packages are written entirely in 32-bit, win32
assembly
> > > > language and I can encrypt or decrypt an 8.4MB file on my Pentium(R)
> 166
> > > in
> > > > 8 seconds. Please give me your feedback!
> > > This should be pretty easy to break given several encrypted blocks
with
> > > known plaintext (either several short messages encrypted with the same
> key
> > > or one long one). As I understand it, your encryption algorithm is
> > > essentially:
> > >
> > > C[i] = ((P[i] ^ x[i]) <<< y[i]) + z[i]
> > >
> > > where:
> > >
> > > P[i] is a byte of plaintext
> > > C[i] is a byte of ciphertext
> > > x[i], y[i], z[i] are key dependent values, and which are repeated
> every
> > > 4096 bytes (and are interrelated)
> > > ^ is xor, <<< is bitwise rotate, and + is addition mod 256
> > >
> > > Because x[i], y[i], z[i] repeat every 4096 bytes, this repetition
length
> > is
> > > called a block.
> > >
> > > Here's how to rederive a good portion of the keying data: for each
byte
> > > within a block, locate two plaintexts that differ in that byte by one
> bit.
> > > If you have at least 16 plaintexts, and the plaintexts are random, you
> > have
> > > a good chance of having such a pair. Then, examine the corresponding
> > > ciphertexts, and see the lsbit where they differ. The rotate that
moves
> > the
> > > plaintext bit that differs to that lsbit ciphertext bit that differs
> must
> > be
> > > correct, thus giving you the 3 lsbits of y[i]. A similar trick can
work
> > if
> > > you don't have a single pair that differs by precisely one bit, but
you
> > have
> > > several pairs with low-hamming weight difference.
> > >
> > > Once you have most of the y[i] values, you can use the
> interrelationships
> > to
> > > derive the 3 lsbits of x[i] and z[i]. Once you have that,
> reconstruction
> > > the rest of the x[i], z[i] values should be straight-forward.
> > >
> > > --
> > > poncho
> > >
> > >
> > >
> >
> >
>
>
------------------------------
From: wint <[EMAIL PROTECTED]>
Subject: Re: Some Enigma Questions -- 150*10^18 settings?
Date: Wed, 24 Jan 2001 01:33:08 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> "David C. Barber" wrote:
> >
> > Q8: Is there a reference that gives the rotor wiring for all German WW II
> > rotors?
>
> See "download internal wiring information" from David Hamer's page:
> http://www.eclipse.net/~dhamer/Enigma1.htm
>
Very interesting, and thanks.
>From the site:
"The machine had a typewriter keyboard, and using three and later
four wheels chosen from a set of five, it scrambled each letter
which was typed in. Later modifications included a plugboard
which swapped up to 10 pairs of letters. Even the simplest three-
wheeled Enigma had a potential of 150 million trillion different
settings. The team at ...."
How is the "150 million trillion" (150 * 10^6 * 10^12 = 1.5*10^20)
computed? My math gives a much lower number -- too low to be
correct. Here goes.
Three rotors, with 26 letters:
26*26*26 = 17,576 starting positions
Three rotors selected from 5:
5*4*3 = 60 rotor choices
Plugboard with 13 wire pairs (26/2, wild guess here):
13! = 6.2 billion ways to plug in the wires (wow!)
Taking the product:
17576 * 60 * 6.2 * 10^9 = 6.5 * 10^15
My error:
1.5 * 10^20 / 6.5 * 10^15 = 23000
that is, my calcs are short by a factor of about 23,000.
Obvious errors? Thanks.
------------------------------
From: "JL" <[EMAIL PROTECTED]>
Subject: Re: collisions risks of applying MD5 or SHA1 to a 48-bit input
Date: Wed, 24 Jan 2001 02:20:47 GMT
Thank you all for the comments. It really helped.
------------------------------
From: AllanW <[EMAIL PROTECTED]>
Subject: Re: Dynamic Transposition Revisited (long)
Date: Wed, 24 Jan 2001 02:24:00 GMT
[EMAIL PROTECTED] (Terry Ritter) wrote:
> When I think of Dynamic Transposition, I think of 512-byte / 4096-bit
> blocks. This stuff scales almost linearly, and 512 bytes is just a
> small buffer.
>
> I suspect that if we run the numbers, some modest minimum size --
> perhaps 128 bits / 16 bytes -- is required for serious strength. We
> can scale it down to look at, of course, but we can't expect strength
> there as well.
Really? I think your original paper made a good case for
allowing short block sizes. Although the 4-byte block
seems to be stretching things too far, a 16-byte block
would work well. In degenerate cases such as all 0's,
this would allow 7 bytes of data followed by 9 bytes of
filler. For typical ASCII data this would allow 10 bytes
of data and 6 bytes of filler. For data that's already
balanced or very nearly so, we could put 15 bytes of
data into a 16-byte block.
Larger block sizes would help to make the overhead
smaller, though. The best case will always require 1 byte
of filler, while the worst case will always require N/2+1
bytes of filler (for N-byte blocks).
As I understood the filler bits to work, the data would
look like this before the transposition begins: if the
data had more 0-bits than 1-bits, it would take the form
XX....XX 00..00 11..11
where X bits represent the data, and then there are 1-8
0-bits followed by 1 or more 1-bits. If the data has
more 1-bits than 0-bits, simply reverse the filler:
XX....XX 11..11 00..00
this time using 1-8 1-bits and then 1 or more 0-bits.
Another way to say this is to show what the filler
would look like for various imbalances. Here I'll
assume that the data has more 0-bits than 1-bits; use
the complement if the opposite is true.
If there are B more 0-bits than 1-bits, then the
filler looks like (in hex):
B=0 0F
B=2 1F
B=4 3F
B=6 7F
B=8 0FFF
B=10. 1FFF
B=12. 3FFF
B=14. 7FFF
B=16. 0FFFFF
B=18. 1FFFFF
B=20. 3FFFFF
B=22. 7FFFFF
B=24. 0FFFFFFF
...and so on.
(Note that the number of data bits is always divisible
by 8 and therefore an even number. This means that the
number of 0-bits, minus the number of 1-bits, must also
be an even number.)
In the worst case for a 16-byte (128-bit) block, the
data would be 56 0-bits. Then the program would add 8
more 0-bits and 64 1-bits.
In the obvious best case, the data has 60 0-bits and
60 1-bits in any order. Then the filler is 0F -- 4
0-bits and 4 1-bits. The best case (15 bytes in a
16-byte block) is also achieved when there are up to
6 more 1-bits than 0-bits or vice-versa -- the filler
still fits in one byte.
If there is any weakness at all to this scheme, it's
that even though you're using a fixed-size block, you
cannot predict in advance how many blocks the message
will need because each block contains between N/2-1 and
N-1 bytes of data. On the other hand, this could be
considered a strength because of the flip side of this
observation: once you know how long the ciphertext is,
you can calculate how many fixed-size blocks were used,
but this does not tell you how long the original
plaintext was. The larger the blocksize, the more true
this is.
Other than that, if there's any reason why a 16-byte
block is less secure than a 512-byte block, it sure
isn't obvious to me! (For whatever that's worth)
--
[EMAIL PROTECTED] is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Robert Larsen" <[EMAIL PROTECTED]>
Subject: Secure game highscore server
Date: Wed, 24 Jan 2001 03:58:32 +0100
Hello
I am developing game applets that sends highscore data back to the server.
How can I do that in a secure way ? It should not be possible to grap the
highscore data and send it again. Also it should not be a problem if someone
decompiled the applet.
Is this possible ?
Thanks in advance
Robert Larsen
[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
******************************
