Cryptography-Digest Digest #668, Volume #9 Sun, 6 Jun 99 01:13:03 EDT
Contents:
"Cipher Systems", Beker & Piper?
Re: evolving round keys
Re: Obscure Code (Christian S. Collberg)
Re: Another source of random numbers (fungus)
Re: Another source of random numbers (fungus)
Re: OTP Problems (Matthias Bruestle)
Re: "Cipher Systems", Beker & Piper? (Terry Ritter)
Re: SCOTT19U pass in nut shell ("Douglas A. Gwyn")
Re: random numbers in ml (Jerry Coffin)
Re: evolving round keys ([EMAIL PROTECTED])
Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1) ("Douglas A.
Gwyn")
Re: "Cipher Systems", Beker & Piper? ("Douglas A. Gwyn")
Re: what cipher? ("Douglas A. Gwyn")
Re: Challenge to SCOTT19U.ZIP_GUY (Jerry Coffin)
Re: Scottu: I actually saw something usefull (SCOTT19U.ZIP_GUY)
Re: SCOTT19U pass in nut shell (SCOTT19U.ZIP_GUY)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] ()
Subject: "Cipher Systems", Beker & Piper?
Date: 6 Jun 99 02:29:33 GMT
I just purchased a fascinating popular book on mathematics, "Mathematics:
The New Golden Age". And I happened to note that at the end of one of its
chapters, a reference is given to the book in the title of the post.
Presumably it covers public key systems - it is said to cover quite a bit
else. The book dates from 1982.
However, it's not one I've heard of.
John Savard
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: evolving round keys
Date: 6 Jun 99 02:26:36 GMT
[EMAIL PROTECTED] wrote:
: It's still a block cipher, the round keys can be forward/reverse
: calculated whereas in a stream cipher it operates in one direction only
: (this is a requirement, however SEAL for example provides random
: indexing in one direction).
There certainly are block cipher modes that produce stream ciphers, in
effect, but I'm unfamiliar with the definition of a "block cipher" that
you're now using.
John Savard
------------------------------
From: [EMAIL PROTECTED] (Christian S. Collberg)
Subject: Re: Obscure Code
Date: 4 Jun 1999 08:28:50 -0700
In article <7j1aia$pjh$[EMAIL PROTECTED]>,
Oliver J. Hanau <[EMAIL PROTECTED]> wrote:
>Does anyone now if there is any kind of source on producing obscure
>code, i.e. code that is hard for an attacker to analyze/debug?
>(Assuming the decryption process takes place in an insecure
>environment, and the attacker attempts to find the key and possibly
>also the algorithm.)
>
>I know that the whole point of such obscure code is *not* to let
>people know how it's done, but maybe there is something despite that
>fact? A source stating that there aren't any sources would also be
>fine.
>
>As this is for an important side-note of a li'l thesis I'm putting
>together, I'd prefer a off-line sources (book/magazine).
>
>Thanks a bunch,
>Oliver.
>
>
>
You may want to try these articles:
Manufacturing Cheap, Resilient, and Stealthy Opaque Constructs, POPL'98
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborsonLow98a/index.html
Breaking Abstractions and Unstructuring Data Structures, ICCL'98
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborsonLow97d/index.html
A related paper is:
Software Watermarking: Models and Dynamic Embeddings, POPL'99
http://www.cs.arizona.edu/~collberg/Research/Publications/CollbergThomborson99a/index.html
Cheers,
Christian
___________________________________________________________________________
Christian Collberg | "Success hasn't gone to my head. I've
http://www.cs.arizona.edu/~collberg | always been a pain in the ass."
University of Arizona | -- Fran Lebowitz
___________________________________________________________________________
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Another source of random numbers
Date: Fri, 04 Jun 1999 16:58:48 +0200
[EMAIL PROTECTED] wrote:
>
> Robert Nemiroff and Jerry Bonnell who run the NASA "Astronomy Picture of
> the Day" web site ("http://antwrp.gsfc.nasa.gov/apod/astropix.html") have
> suggested using the digits of irrational numbers like Pi, e, and the
> square root of two, etc., as a source of random numbers. See Bob's page
> at "http://antwrp.gsfc.nasa.gov/htmltest/rjn_dig.html" where values of
> these numbers are given to several million decimal places.
>
> Is this idea widely known?
>
Yes and it doesn't work. The digits of such numbers may be
irrational, but they're not random.
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: fungus <[EMAIL PROTECTED]>
Subject: Re: Another source of random numbers
Date: Fri, 04 Jun 1999 18:50:54 +0200
almis wrote:
>
> [EMAIL PROTECTED] wrote in message <7j2eq7$ajq$[EMAIL PROTECTED]>...
> |
> |Is this idea widely known?
>
> Yes!
...and so is the one about using the Mandelbrot set as a source
of "chaos".
--
<\___/>
/ O O \
\_____/ FTB.
------------------------------
From: [EMAIL PROTECTED] (Matthias Bruestle)
Subject: Re: OTP Problems
Date: Fri, 4 Jun 1999 17:54:07 GMT
Mahlzeit
Andrew Haley ([EMAIL PROTECTED]) wrote:
> Matthias Bruestle ([EMAIL PROTECTED]) wrote:
> : I doubt it [iButton] can withstand a skillfull student. (See papers of
>Kuhn&Anderson)
> Is this assertion based on any knowledge?
> The last time that I saw Markus Kuhn he recommended something like an
> iButton to counter his methods of attack.
As I remember the iButton is a batterie puffered RAM. So throwing it
in liquid nitrogene should preserve the data long enough to disassemble
and repower it.
There is somewhere a paper (maybe also from Kuhn) about the security
of computer modules for nuclear weapons. Maybe this could be called
tamperproof.
Mahlzeit
endergone Zwiebeltuete
--
PGP: SIG:C379A331 ENC:F47FA83D I LOVE MY PDP-11/34A, M70 and MicroVAXII!
--
When a program is useful it must be changed,
when it is useless it must be documented.
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: "Cipher Systems", Beker & Piper?
Date: Sun, 06 Jun 1999 04:15:24 GMT
On 6 Jun 99 02:29:33 GMT, in <[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] () wrote:
>I just purchased a fascinating popular book on mathematics, "Mathematics:
>The New Golden Age". And I happened to note that at the end of one of its
>chapters, a reference is given to the book in the title of the post.
>
>Presumably it covers public key systems - it is said to cover quite a bit
>else. The book dates from 1982.
>
>However, it's not one I've heard of.
Well, I can only do so much: I just checked and -- yes, indeed --
found it in the references from no less than three of my Cryptologia
articles from the early 90's, plus the crypto DSP article.
Basically, Cipher Systems is your general crypto text (including
various math exercises) from that period. That was a time -- now long
gone -- when there were few such books, and crypto information was
much more difficult to get than probably even can be imagined now. It
does cover public key crypto (in the last 24 pages), and reprints the
DES standard at the end of the chapter on Feistel and other block
ciphers.
Cipher Systems has much more about feedback shift registers (FSR's)
than we find in most modern texts. There is an interesting figure on
p. 250 that shows what I would call an "autokey" with ciphertext
feedback: The ciphertext is shifted through a register and taps
generate confusion which is combined with plaintext. (This is for
discussion, folks; it is not strong.)
The text also has more crypto statistics and practical cryptanalysis
of older systems than we find in modern texts; for example, they talk
about attacking the M209 quite a bit. In that sense it is more
down-to-earth than modern texts. It has two chapters on classical
Shannon theory, the chapter on LFSR's and another on NLFSR's. They
talk about a key hierarchy and message keys. There is a chapter on
secure speech, which is interesting enough (and they have another
whole book on it), but their analog approach was obsolete even at the
time.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: SCOTT19U pass in nut shell
Date: Sun, 06 Jun 1999 04:17:32 GMT
"SCOTT19U.ZIP_GUY" wrote:
> ...
> Cn= E{ ( Cn-1 xor Pn) + Pn+1}
> where E{ } is any possible 19 bit single cycle look up table.
> ...
I don't know why you spent so much time explaining the other stuff,
which is just how to walk through arrays, etc. Presumably the
core of the encryption is the above formula, and whatever
security there is must reside in the E-table, since the rest of
the algorithm is invariant (and known to an attacker).
I think the interesting question is, why 9 and 19 bits? Is there
some theory about this approach such that those are optimal
parameters in some sense?
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Crossposted-To: comp.sys.cbm
Subject: Re: random numbers in ml
Date: Sat, 5 Jun 1999 22:20:03 -0600
In article <7ja549$n56$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> Unless they prefer assembly language. Naturally, there are bound to be
> some 'C' aficionados around, and a fair number of assembly language
> aficionados around, too.
The problem here is that they not only need to understand assembly
language, but the specific assembly language you use. I have a
reasonable understanding of at least a half dozen different assembly
languages, and I'd still have to pull out a book to be certain exactly
which instructions you used did what (if anything) with the carry
flag; details like this vary widely between different processors.
> Unless we exhaustively analyze the entire set of
> readers of sci.crypt, how are we to conclude that 'C' is the preferred
> language for talking about random number generators?
An absolutely conclusive proof might require an exhaustive analysis,
but if you're honestly trying to find the truth, I'm convinced that
empirical evidence means quite a bit. I've seen dozens of algorithms
posted in C. They've gotten quite a few responses, most of which
indicated an understanding of the algorithm. By contrast, in your
case, there were very few responses about the algorithm proper, and I
don't think even one displayed a complete understanding of what was
going on. I once used 6502 assembly language quite a bit, and I still
had to pull out one of my old books to check a couple of details.
> >Ultimately, cross-posting between the two groups is probably not the best
> >way to go;
>
> Unless there are more people conversant with assembly language than you
> think there are.
So far, every indication is that if anything, there are even fewer
than I would have guessed until you posted your code. Of course, as I
mentioned above, there's more to it than just an understanding of
assembly language in general -- one needs to know the particular
processor you used. At various times I've written assembly language
code for everything from the Intel 8008 to a CDC Cyber mainframe, and
at least a couple dozen others in-between. Though you're obviously
familiar with at least one assembly language, chances are pretty fair
that if I posted something in Compass (the CDC Cyber assembly
language) you'd have almost no clue of what was going on at all.
I don't mean that as an insult -- it just happens that CDC mainframes
are about as different from 6502s as humanly possible. Their main
registers are 60 bits wide, and nearly everything they do is in
floating point rather than integers. They had no convenient way of
working with 8-bit items at all.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: evolving round keys
Date: Sun, 06 Jun 1999 03:29:50 GMT
> Yes, David Wagner has sent me some very helpful comments via E-mail as
> well.
>
> If the subkeys recur in a regular sequence, that might be true, but
if the
> subkeys are varied in a sophisticated fashion, so that it's not easy
to
> tell when the same subkey is ever used again, though, I would think
that
> differential and linear attacks would be hindered - greatly. (Of
course, I
> suppose D.W. could get picky, and note that one could do a birthday
attack
> on the IV...)
If you have a strong enough char. then you can simply remove the delta
from adjacent blocks.
> If you swap the s-box entries that are _used_ in a block
encipherment, you
> would be using a patented technique: Terry Ritter's Dynamic
Substitution.
> But yes, it _is_ a good idea.
How can you patent a swap? It's a table (or function) which is
dynamically updated. You cannot patent a swap, or at least you
shouldn't.
Tom
--
PGP public keys. SPARE key is for daily work, WORK key is for
published work. The spare is at
'http://members.tripod.com/~tomstdenis/key_s.pgp'. Work key is at
'http://members.tripod.com/~tomstdenis/key.pgp'. Try SPARE first!
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 8Bit encryption code. Just try and break it. - code3.ecr (0/1)
Date: Sun, 06 Jun 1999 04:26:11 GMT
[EMAIL PROTECTED] wrote:
> Note that the ranking of security includes higher levels of security
> beyond top secret. One of the highest is top secret/black/crypto.
What government are you talking about? That's not how we do it here.
> Tell us, does the NSA maintain secrecy to protect their ciphers from
> adversaries or to protect their massive budget from the public?
It can't be to protect their budget from the public, because their
overall budget *is* public these days, and has previously been
closely estimated by public watchdog groups even when it was hidden.
On the issue of keeping cryptosystem details secret, it's a good idea
because it forces the enemy to do more work, but in designing a
cryptosystem, it is taken as an axiom that an enemy could learn its
principles of operation, and the design must provide adequate
security even in such a case.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: "Cipher Systems", Beker & Piper?
Date: Sun, 06 Jun 1999 04:08:29 GMT
[EMAIL PROTECTED] wrote:
> Presumably it covers public key systems - it is said to cover quite a bit
> else. The book dates from 1982.
I have it in my library. It is easier reading than many of the
well-known texts on cryptography, and fairly thorough. Two topics
it covers in more depth than other crypto books I know of are Hagelin
cryptanalysis and speech security systems.
"... the aim of this book is to provide a comprehensive introduction
to the subject of protecting and securing communications."
I'd say if you already have a book of that sort and are happy with
it, there is no need to acquire Beker&Piper, but if not, their book
is worth a try.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: what cipher?
Date: Sun, 06 Jun 1999 04:30:59 GMT
David Wagner wrote:
> The cryptanalysis problem looks much harder when the taps to the main
> register are not known, or when multiple stages of this construction
> are applied with differently-tapped registers. Who knows? Maybe such
> an approach might prove secure, if sufficient care is taken.
Actually, LFSR isn't particularly secure, and the taps can be found,
although I don't think the methodology has been published. I was
instead referring to the further generalizations of the idea, such
as nonlinear combinators.
------------------------------
From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 5 Jun 1999 22:20:00 -0600
In article <7jbo2g$c1c$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> I would suggest that he actually gives out the guidelines for the
> design criterion, so that it can be fully optimized.
Instead of that, why don't we just quit worrying about his code,
algorithm, etc., and move onto something useful, such as designing an
algorithm we all agree we can trust. A few criteria I'd put into the
mix are:
1) A large enough key that not only is a brute-force attack
impractical, but breaks would have to be large to mean anything.
2) Resistant to currently known attacks.
3) Reasonable expectation of performance no worse than DES.
4) A combination of at least two fundamentally different types of
encryption.
I also kind of generally like Scott's idea that changing bits anywhere
in the message being encoded can have effects anywhere (and
everywhere) in the encoded text. With a typical block cipher, it can
have effects anywhere in the same block. Using a CBC or similar mode,
it also affects bits in later parts of the encrypted text, but a
change later in the plain text can't affect bits earlier in the
encrypted text.
Putting some concrete ideas to these, I'd say 256 bits is easily a
large enough key. To satisfy the other criteria, I think it would be
sensible to combine a stream cipher and a block cipher. I think first
I'd run the block cipher in CBC mode, then run the stream cipher,
running the file from the end backwards to the beginning. By running
one cipher in each direction, changes anywhere in the plain text can
affect all parts of the encrypted text.
Working backwards is likely to be slower than forwards, and this
effect is likely to be at least as large for the stream cipher as the
block cipher. This means the decryption would likely be faster than
encryption -- since a file must be decrypted at least as often as its
encrypted to be of any use, (and may well be decrypted more often if
it's being transmitted to a number of people) it makes sense to me to
optimize decryption over encryption.
Using a 256-bit key, and a combination of a stream cipher and a block
cipher would mean that you'd have to find EXTREMELY effective attacks
on two fundamentally different kinds of ciphers to even begin a
practical attack on such an algorithm. You'd have to reduce the
overall difficulty by a factor of around 2^200 to create a practical
attack.
For the sake of comparison, linear cryptanalysis is considered quite
effective against DES. IIRC, "quite effective" in this case means
that it gives a reduction in difficulty on the order of 2^16 or so
compared to a brute-force attack. You need a MUCH bigger break than
that to begin a meaningful attack against a 256-bit key.
For the moment, I'm leaving the details of key schedule, contents of
S-boxes, polynomial used in the stream cipher (assuming it's even an
LFSR), etc., undefined -- it's clearly premature to try to work out
such design details until all the fundamental criteria are agreed
upon.
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Scottu: I actually saw something usefull
Date: Sun, 06 Jun 1999 05:54:42 GMT
In article <7jcecf$i4o$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>On his page there is a brief description of the algorithm. I found this
>
>Cn = S{ (((Cn-1) XOR (Pn)) + (Pn+1))mod 2^W }
>
Glad some one actually looked before they started
crita sizing. The mod 2*W was from horst. I told him
that since everyting was done in 19 bits it was not needed
but he felt it made it clearer.
>Which happens to be the round function, where
>
>Cn is the ciphertext at n
>S is the large S-box
>Pn is the plaintext at n
>
>Now I know little of actually starting an attack, but from what I
>briefly saw, he runs from 0-n 25 times. Errors in the ciphertext
>propagate forwards only though (note Cn-1 usage). If he ran this
>forwards and backwards this might help (note: would have to use Cn+1
>which I did not see on his page).
>
What your missing is that it does not just propagate forwards. It actaully
wraps around. Also there is something else about the way it wraps. Most
ciphers in encrypt in the forward firection of a file and decrypt in the
forward direction of a file. But one could write a program to read the back
of the file first and still decrypt in reverse direction. But most people
do not do this since there is no need. A file encrypted with scott19u
can not be decrypted in the forward direction of reading a file. It must
be decrypted in the backward direction since there is not enough
information to decrypt the first few blocks on any pass until the rest
of file from the bottom up has been decrypted.
>Which leads me to think that the first set of n-25 words leaks info
>about the s-boxes. The key schedule does not look too proper though..
>
>
>---snip----
>
>Step 1: Create a memory array of 64K words (FFFF words in hexadecimal
>terminology). Call this array List1[i]. These words will have addresses
>i from 0 to FFFF hex. The values initially stored in these locations
>are simply 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, f, 10, 11,
>12, ... etc. up to FFFF hex. Each of these values will be selected only
>once by the algorithm, and the value will be put in a location of the S-
>Box memory array that is chosen by Rules defined below. After a value
>from location i is put in the S-Box, location i is written with a new
>value, according to the Rules defined below.
>
>Step 2: Use the keyraw.key file with location pointed to by j. This
>keyraw.key file may have less than 64K words. Call each word key[j].
>Start at location j=0 and use the value at that location according to
>the Rules defined below to make an entry in the S-Box. Then j will be
>incremented through the whole keyraw.key file, and j will wrap around
>as many times as needed to finish making the S-Box.
>
>Step 3: Set x=1. Take the key value at j=0, add 1 to it, mod ((2^16)-1-
>x) and put that number in S-Box location 0. Place key[j]+1 in List1[S-
>Box[j]].
>
>Step 4: Set x=2. Take the key value at j=1, add 1+j to it, mod ((2^16)-
>1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
>List1[S-Box[j]].
>
>Step 5: Set x=3. Take the key value at j=2, add 1+j to it, mod ((2^16)-
>1-x) , and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in
>List1[S-Box[j]].
>..
>..
>..
>Step Y: Increment x and j. Take key[j], add 1+j to it, mod ((2^16)-1-
>x), and place that value in S-Box[S-Box[j-1]]. Place key[j]+1 in List1
>[S-Box[j]].
>
>Simple, yet oh so powerful! Right? Get it? Huh? No? Well, tough. Learn
>it, love it, live it.
>---snip----
>
>Looks to complicated. I would love to see a pro hack at it. Why
>doesn't he just use a key schedule like RC4? RC4 is really simple
>(that's why I like it) to implement and avoids implementation errors.
>
>I will have to read more of the page:
> http://members.xoom.com/ecil/page2.htm
>
>Basically it's a codebook cipher using the previous/next cipher/plain
>text as entries into the table. I think it's a little too simple
>(the 'round function') to be sure.
>
>Tom
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: SCOTT19U pass in nut shell
Date: Sun, 06 Jun 1999 06:05:11 GMT
In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>"SCOTT19U.ZIP_GUY" wrote:
>> ...
>> Cn= E{ ( Cn-1 xor Pn) + Pn+1}
>> where E{ } is any possible 19 bit single cycle look up table.
>> ...
>
>I don't know why you spent so much time explaining the other stuff,
>which is just how to walk through arrays, etc. Presumably the
>core of the encryption is the above formula, and whatever
>security there is must reside in the E-table, since the rest of
>the algorithm is invariant (and known to an attacker).
>
>I think the interesting question is, why 9 and 19 bits? Is there
>some theory about this approach such that those are optimal
>parameters in some sense?
I chose 19 bits for the reason that if one want to express each
possible 19x 19 bit single cycle S-table as a binary number it
would fit on a 1.44 meg disk. a 20 bit version would need a key
size larger than 1.44 megs. The 9 bit rotation was really more
arbitrary. I had scott16u which already had an 8 bit roatation and
8 bits would have been easier. But I guess I just had a hair up
my ass to make it 9. There was no real reason other I liked it.
And I felt others would hate it. Since everything is done is
8 byte increments.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
http://members.xoom.com/ecil/index.htm
NOTE EMAIL address is for SPAMERS
------------------------------
** 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
******************************
