Cryptography-Digest Digest #593, Volume #12 Fri, 1 Sep 00 21:13:00 EDT
Contents:
Re: Capability of memorizing passwords ([EMAIL PROTECTED])
Quick, simple and easy cipher? ("James Blythe")
Encryption gurus for beta testing wanted! ("William T")
Re: 4x4 s-boxes (Terry Ritter)
Re: NEWBIE!!! Zodiac killer's encryption... ("Joseph Smith")
Re: Capability of memorizing passwords (Mok-Kong Shen)
Re: Capability of memorizing passwords (S. T. L.)
Re: Patent, Patent is a nightmare, all software patent shuld not be allowed (Jerry
Coffin)
Re: blowfish problem ("Douglas A. Gwyn")
Re: one-time pad question ("Douglas A. Gwyn")
Re: 4x4 s-boxes ("Douglas A. Gwyn")
Re: NEWBIE!!! Zodiac killer's encryption... ("Douglas A. Gwyn")
Re: New algorithm for the cipher contest ("Scott Fluhrer")
Re: Capability of memorizing passwords (Mok-Kong Shen)
Re: Capability of memorizing passwords (Paul Rubin)
Re: Capability of memorizing passwords (S. T. L.)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Capability of memorizing passwords
Date: Fri, 01 Sep 2000 20:19:52 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> It is often said that it is difficult for people to
> memorize random passwords (commonly 8 characters). I am
> very surprised to read in a magazine that the record of
> memorizing a bit sequence, given a time of 30 minutes, is
> 2745 bits! So brain's capability of processing random
> stuffs doesn't seem to be too bad after all.
And the record for running a mile is well under four minutes, so human
running speed doesn't seem to be too bad after all. ;)
Human memory is very poorly understood, and in my experience, differs
greatly from person to person. I would expect the average to be much
lower than that.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: "James Blythe" <[EMAIL PROTECTED]>
Subject: Quick, simple and easy cipher?
Date: Fri, 1 Sep 2000 21:36:05 +0100
I'm looking for a pen, paper and calculator cipher that is quick and easy to
understand, and could possibly have the advantage of being simulated on a
computer. Solitaire and other such long-winded systems are great but I don't
need that level of security and they take too long. I've developed my own
system using simple multiplication of integers to create a keystream, but
it's so simple I think I must be missing something and it's probably
completely useless. Does anyone know of a system?
Regards,
James Blythe
------------------------------
From: "William T" <[EMAIL PROTECTED]>
Subject: Encryption gurus for beta testing wanted!
Date: Fri, 1 Sep 2000 21:58:23 +0100
Know about encryption and would like free software? Then please respond to
this as I need 5 willing beta testers to test some software. This software
can be found at www.tracz.freeserve.co.uk and offers a new way to encrypt
and compress things. If you want to help and recieve 2 free products then
please reply to [EMAIL PROTECTED] with a subject line of "BETA TEST"
(no-quotes). Even if you are not selected for the beta process I still need
comments about it to help better the product!
WT
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: 4x4 s-boxes
Date: Fri, 01 Sep 2000 21:17:54 GMT
On Fri, 01 Sep 2000 14:06:14 -0400, in <[EMAIL PROTECTED]>,
in sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>Tim Tyler wrote:
>> [EMAIL PROTECTED] wrote:
>> : [EMAIL PROTECTED] (Mack) wrote:
>> :> bent is usually used to refer to functions which have non-linearity
>> :> which is maximum. They only occur on functions of 2n variables
>> :> and are not balanced. You appear to be refering to nearly bent
>> :> functions.
>> : Ahem, according to "Perfect nonlinear Sboxes" by Kaisa Nyberg from
>> : Eurocrypt '91, we have and I quote.
>> : Definition 2.1: A function F: Zn/q -> Zq is bent if |F(w)| = 1 for all
>> : w.
>> Bent functions have maximum non-linearity.
>
>Actually the correct definition is the one involving the FT.
>There are several ways in which "nonlinearity" might be measured,
>Ritter's not being the only one.
Let me say one more time that -- as far as I am aware -- "my"
definition of nonlinearity is "the" standard definition as used in
modern open cryptography. Moreover, I am unaware of any competing
definition which would require us to choose one or the other. As far
as I know there is only *one* "nonlinearity" in open cryptography, a
concept which can be and often is expressed in different ways.
The idea of "nonlinearity" as a measure of not-linearity -- the number
of bits which must change to reach linearity -- is both fundamental
and appealing. For one thing, we can do such a computation by hand
without invoking any transform at all. Yes, we can use a transform to
speed that up, but we don't *need* a transform to understand what is
happening. In this way, understanding nonlinearity does not require a
deep understanding of the transform concept. This is a big, big
advantage.
>Any nonlinearity property of
>bent functions is a consequence of the FT-based definition,
>and would depend critically on the way one defines the measure
>of nonlinearity.
While the FT originally defined "bent," most modern treatments use the
FWT. It appears that a natural consequence of any such structure is
to be necessarily unbalanced.
>It is true that under a reasonable definition
>of nonlinearity, bent functions are necessarily highly nonlinear.
>From the cryptanalytic point of view, the FT property is more
>important.
As far as I know, in modern open cryptography, these concepts are the
same.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Joseph Smith" <[EMAIL PROTECTED]>
Subject: Re: NEWBIE!!! Zodiac killer's encryption...
Date: Fri, 01 Sep 2000 21:29:36 GMT
The "Times 17" book and the follow-up book Gareth Penn published
in 1999 do at first seem goofy, but become interesting if you accept
some assumptions, which unfortunately the author does not spell out
clearly. The primary assumption is that the unusual spelling errors in
the plaintext letters that accompanied the ciphertexts were caused by
a hidden message. This takes the author into Steganography instead
of cryptanalysis, so it becomes hard to decide how much evidence is
required to separated a realistic technique from a goofy one.
To make matters harder, the author assumes that the hidden message
is a collection of statements or relationship claims rather than an
English sentence like "I murdered Paul". These statements are expressed
graphically in a 17 by N matrix or a 7 by N matrix for calendar
relationships.
The author tries to validate this approach by showing that the Zodiac
letters
have much higher content than a text like the Gettysburg address.
Given the number of degrees of freedom in the "decryption" process
it is hard to say whether these results mean anything. There is no
established
way to measure the "unicity distance" for this kind of Stego (i.e., how many
valid statements are required to decided that the decryption process is
correct for a message of a given size).
The author concludes by naming a person who work for Arthur D. Little
Consulting who was in the right places at the right times, and who
as a graduate student wrote about graphically encoding multiple
messages inside of a cover plaintext. Oddly, when the same techniques
are applied to a document the named person published, it also uncovers
some of the same statements and relationships.
>
>The book is "Times 17: The Amazing Story of the Zodiac Murders in
>California and Massachusetts, 1966-1981" by Gareth Penn. It's listed
>as out-of-print on Amazon.com but isn't worth trying to get unless you
>want to see some really goofy cryptanalysis.
>
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Fri, 01 Sep 2000 23:44:46 +0200
[EMAIL PROTECTED] wrote:
>
> Human memory is very poorly understood, and in my experience, differs
> greatly from person to person. I would expect the average to be much
> lower than that.
No question about that. But 8 ASCII characters amount
to 56 bits only and we have them in readable character
format that should facilitate memorizing.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Subject: Re: Capability of memorizing passwords
Date: 01 Sep 2000 21:48:33 GMT
<<No question about that. But 8 ASCII characters amount
to 56 bits only and we have them in readable character
format that should facilitate memorizing.>>
Goofy. Use a large dictionary of 6-letter words (and below) to translate a
128-bit sequence into a 10-word passphrase, easily memorizable. That's what I
did. Works easily.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Patent, Patent is a nightmare, all software patent shuld not be allowed
Date: Fri, 1 Sep 2000 15:51:56 -0600
In article <h3Sr5.7153$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
[ ... ]
> Not a trivial task. The claims are what matters and they must
> be evaluated literally.
...sort of. Means plus function claims are restricted to what's in
the body of the patent. Furthermore, the patent's file wrapper may
limit the scope of the patent in ways that aren't obvious from the
wording of the claims. In a situation like this, you're likely to
hear the court use the term "estoppel."
The basic idea is that if you quit claiming coverage of something to
get the patent, that you shouldn't later be able to re-claim coverage
of that same thing under the doctrine of equivalents.
Finally, it's worth noting that while you're correct that what's in
the body isn't necessarily claimed, the body often DOES define how
particular terms are used in the claims, so terms may not always mean
exactly what they appear to unless you've studied the body of the
patent first. At least in my experience this is particularly common
in patents that really DO represent fundamental advances, that are
often written well before the rest of the world decides on exactly
how to define terms in this area.
--
Later,
Jerry.
The Universe is a figment of its own imagination.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: blowfish problem
Date: Fri, 01 Sep 2000 17:55:56 -0400
"Trevor L. Jackson, III" wrote:
> "Douglas A. Gwyn" wrote:
> > On the PDP-11, operations with signed char tended to be faster
> > than with unsigned char, due to properties of the instruction set.
> Interesting. Must have been the versions before my time. I recall
> nothing special about signed chars on -35, -60, -70, and the LSI-11
> subfamily.
The PDP-11 instruction set included operations on "bytes"
(8-bit addressable units on the PDP-11) and "words".
Registers were always full words. The byte operations
would automatically sign-extend; thus if signed chars
were wanted the right thing occurred, but if unsigned
chars were wanted the sign-extension had to be masked
off, which made for slower code.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: one-time pad question
Date: Fri, 01 Sep 2000 17:57:23 -0400
Jim wrote:
> So it must follow that, because the perfectly random key does not
> exist, that any and all OTP can be broken?
No, the conclusion is not true and neither is the hypothesis.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: 4x4 s-boxes
Date: Fri, 01 Sep 2000 18:10:46 -0400
Terry Ritter wrote:
> While the FT originally defined "bent," most modern treatments use
> the FWT.
? What does the definition of bent function look like in terms
of Walsh transforms? Is it as simple as the FT version? Keep in
mind that it has to single out precisely the same family.
> As far as I know, in modern open cryptography, these concepts
> [maximal nonlinearity and uniform Fourier weights] are the same.
They can't be the same, because the latter defines a bent function
but you guys are claiming that bent functions aren't maximally
nonlinear.
The reason the FT property is important is that it says there is
no distinctive "bulge" in the distribution. Bulges are exploitable,
although so far as I know there is no open publication explaining
how -- the nearest I've seen are some papers from Seberry's crowd.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NEWBIE!!! Zodiac killer's encryption...
Date: Fri, 01 Sep 2000 18:16:06 -0400
Joseph Smith wrote:
> ... it becomes hard to decide how much evidence is
> required to separated a realistic technique from a goofy one.
Not really. It is easy to find hidden messages in texts,
even when they weren't put there deliberately. What is
much rarer is a deliberately hidden message, which to be
valid *must* have a simple rule for decoding, e.g. "every
third letter after a punctuation mark". If somebody
claims to have found a hidden message using a decoding
system much more complex than that, or involving injection
of the decoder's own judgment at several stages, then it
is virtually certain that he is delusional.
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: New algorithm for the cipher contest
Date: Fri, 1 Sep 2000 16:54:35 -0700
Alexis Machado <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
>
> "Scott Fluhrer" <[EMAIL PROTECTED]> wrote in message
> news:8o8rni$ehm$[EMAIL PROTECTED]...
> >
> > I believe I have a way that, given K[3] (which is the fourth
> multiplicative
> > key), distinguishes it from randomness with a relatively few amount of
> > chosen plaintexts and effort, and the actual chosen plaintexts do not
> depend
> > on K[3]. This immediately leads to a method of rederiving K[3] with
about
> > O(2**64) effort and circa 100-1000 chosen plaintexts. (It actually
> consists
> > of two tests, and the success rate of either depends on the value of
K[1],
> > and they both combined cover the entire range of K[1]'s)
> >
> > Outline of Nimbus (which is what he calls the cipher in the
> documentation):
> > - He treats the plaintext data as a 64 bit word
> > - A round (in the encrypt direction) consists of:
> > - Xoring in key dependent value into the data word. This key
dependent
> > value is called K[4]..K[7] in the documentation
> > - Reversing the order of the bits of the data word (so bit 63 gets
moved
> > into bit 0). He calls this operation "mirroring" in the literature.
> > - Multiplying (mod 2**64) a key dependent odd value into the data
word.
> > This key dependent value is called K[0]..K[3] in the literature
> > - The cipher consists of 4 of these rounds. I will assume that the key
> > dependent words used in each round is independently chosen.
> >
> > Now, assume the attacker knows K[3]. Then, he can logically strip out
the
> > last multiplication (by taking any ciphertext he has, and multiplying it
> by
> > the inverse). In addition, since my attack will care only about bit
> > differentials, we can also ignore the xor/mirror steps in the fourth
> round,
> > because they do nothing to mask that.
> >
> > The first test is as follows: encrypt pairs of plaintexts. Each pair
has
> an
> > xor differential in bit 0, and has common random data in the other bits
> (and
> > the randomness assumption is importent). Following through the pair
> through
> > the cipher, we see that, after the first round, that pair now has an xor
> > differential in bit 63 and random data in the other bits. Then, in the
> > second round, the xor does not affect the differential, and the mirror
> > changes it so the values has an xor differential of 1, or as it is more
> > convienent to look at it, an additive differential [1] of 1. This means
> > that, after the multiplication, the values has an additive differential
of
> > K[1], and since we are at a random point, this means that there is a
> > differential in bit 63 with probability P = K[1] / 2**63 if K[1] <=
2**63
> > and P = 2 - K[1] / 2**63 if K[1] >= 2**63. Then, after round 3, bit 0
> will
> > have a differential with probability P. If P is greatly different from
> 1/2,
> > that is, if K[1] is far from either 2**62 or 2**62+2**63, then a
> relatively
> > few number of pairs will distinguish it, in that bit 0 of round 3 will
> have
> > a differential either much more often than expected, or much less often
> than
> > expected.
> >
> > The second test is as follows: encrypt quads of plaintexts, each quad
> > consisting of all four distinct bit 0/bit 1 values, and common random
data
> > in the upper 62 bits. Then (following the logic above), after the
second
> > multiplication, the quad will be X, X+K[1], X+2K[1], X+3K[1] in some
> order.
> > If K[1] is approximately 2**62 or 2**62+2**63, then these values will
have
> > four different values in the upper 2 bits with good probability, and so,
> > after the third round, each of the quad will have a distinct value in
the
> > lower 2 bits with much higher probability than randomness, and so that
> > yields a distinguisher when K[1] is in the right range.
> >
> > By some odd coincidence, the second test yields a distinguisher exactly
> when
> > the first test does not. So, no matter what K[1] is, we have a
> > distinguisher (and, as a side bonus, we gain some information on K[1])
> >
> > [1] In this case, I refer to an additive differential of K as meaning
that
> > the pair is (X,X+K), without regard to which of the pair is X and which
is
> > X+K.
> >
>
> I could verify that the 3rd round outputs the differentials as stated by
> Scott. In the 4th round this effect stops, leading to a O(2**64)
> choosen-plaintext method. I think it's an excellent work and helped me to
> understand this cipher better.
>
> After talking to Scott, I decided (for precaution) to propose the addition
> of one more round. The encrypting function would become:
>
> Block CipherBlock (Key K, Block B)
> {
> B = Mirror(B ^ K[5]) * K[0];
> B = Mirror(B ^ K[6]) * K[1];
> B = Mirror(B ^ K[7]) * K[2];
> B = Mirror(B ^ K[8]) * K[3];
> B = Mirror(B ^ K[9]) * K[4];
>
> return (B);
> }
>
> This doesn't add any complication to the cipher. Scott's method applies in
> the same way, but now is O(2**128).
Actually, to be unutterly pedantic, I don't think you can do my method in
only O(2**128) steps against the revised cipher. With only four rounds,
after assuming the round 4 multiplier subkey, you could ignore the round 4
xor subkey, because that never affected the differentials I was looking at.
However, with five rounds, you don't know what the differential was after 3
rounds if you assume the last two multiplicative subkeys, because the round
5 xor subkey messes things up.
--
poncho
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Capability of memorizing passwords
Date: Sat, 02 Sep 2000 02:31:22 +0200
"S. T. L." wrote:
>
> Goofy. Use a large dictionary of 6-letter words (and below) to translate a
> 128-bit sequence into a 10-word passphrase, easily memorizable. That's what I
> did. Works easily.
I suppose not everyone knows your technique. Could you
give an example that works, i.e. automatically translates
back to the arbitrarily given 128 bit?
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Capability of memorizing passwords
Date: 2 Sep 2000 00:31:22 GMT
Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
>> Goofy. Use a large dictionary of 6-letter words (and below) to translate a
>> 128-bit sequence into a 10-word passphrase, easily memorizable. That's what I
>> did. Works easily.
>
>I suppose not everyone knows your technique. Could you
>give an example that works, i.e. automatically translates
>back to the arbitrarily given 128 bit?
I think the idea is to make sure the passphrase has 128 bits of entropy,
not to be able to recover the initial passphrase. But anyway, say there's
8192 (= 2**13) words in the dictionary. Just choose 10 of them at random
and use that as a passphrase, and there's your 128 bits.
------------------------------
From: [EMAIL PROTECTED] (S. T. L.)
Date: 02 Sep 2000 00:33:05 GMT
Subject: Re: Capability of memorizing passwords
<<I suppose not everyone knows your technique. Could you
give an example that works, i.e. automatically translates
back to the arbitrarily given 128 bit?>>
Well, um, I'd expect that a program would be able to accept arbitrary-length
passphrases, no? Translating from 128 random bits to a 10-word passphrase is
as simple as breaking it up into chunks of bits and looking up the words in a
list of 8,192 words (or however many you have; I used 8,192 words). Doing the
reverse would require the same list.
-*---*-------
S.T.L. My Quotes Page * http://quote.cjb.net * leads to my NEW site.
My upgraded Book Reviews Page: * http://sciencebook.cjb.net *
Optimized pngcrush executable now on my Download page!
Long live pngcrush! :->
------------------------------
** 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
******************************
