Cryptography-Digest Digest #666, Volume #9 Sat, 5 Jun 99 18:13:03 EDT
Contents:
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: what cipher? (Terry Ritter)
Re: what cipher? ([EMAIL PROTECTED])
Re: Challenge to SCOTT19U.ZIP_GUY (SCOTT19U.ZIP_GUY)
Re: Challenge to SCOTT19U.ZIP_GUY (Tim Redburn)
Re: what cipher? (David Wagner)
Re: DES Effective Security Q (Nicol So)
Re: Hot on the heels of hushmail.... (John Kennedy)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 05 Jun 1999 20:45:23 GMT
In article <7jbo2g$c1c$[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>
>>
>> The other version can still be there as the 'fully optimized'
>implementation.
>
>Sure. Well let's see it's dang slow. It would take a miracle to make
>it at least 3 times as *slow* as Blowfish (or similar). It also
>requires a lot of memory, and key material. Which suggests poor use of
>available resources, and bad key management. Smaller keys are not
>always worst, and you have to realize that. A key of 128 bits where
>the entire key is used effective will require on average 2^127 trials
>to break (unless the cipher has some exploitable weakness).
>
>I would suggest that he actually gives out the guidelines for the
>design criterion, so that it can be fully optimized. Maybe we can use
>a similar idea with say lots less key/memory requirements. The use of
>19 bit words is not a good idea. Maybe 19 bit inputs into a 19x32 sbox
>or something. But this would be a rather large s-box, unless it was
>derived with some sequence (geometric/arithmetic...).
>
>Tom
Tom if your really a 17 year old kid and know C. Why don't you look it
at. The guide lines are there in the code.
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] (Terry Ritter)
Subject: Re: what cipher?
Date: Sat, 05 Jun 1999 19:59:06 GMT
On Sat, 05 Jun 1999 19:52:33 GMT, in <[EMAIL PROTECTED]>,
in sci.crypt [EMAIL PROTECTED] (Terry Ritter) wrote:
>[...]
>Presumably, once we have fast stepping and the size of the register,
>and the key, we can just step 2**n - 1 positions back to plaintext.
I should have said that if we step <key> places from plaintext, we can
continue around through ((2**n - 1) - <key>) positions back to
plaintext.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: what cipher?
Date: Sat, 05 Jun 1999 18:48:47 GMT
> Since you looked at the article, would you mind if I ask a few
questions?
>
> 1. Is this used one-bit-at-a-time (drop a plaintext bit in, step,
repeat)
> or do you drop in the entire plaintext (or at least as much will
fit in
> the register) all at once?
Probably a bit at a time. The PnP bios does a checksum this way too.
> 2. Is the output one bit from the main register, or is the entire
contents of the register?
It would have to be the output, you cannot just use the register, since
you will not know how to reverse the process without the output.
> 3. How on earth do you decrypt?? :-)
Well if you have the output and the register you can step backwards
can't you? I can't imagine this being very secure...
Maybe if the original poster could clarify this a bit?
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: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 05 Jun 1999 20:32:02 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tim
Redburn) wrote:
>On Sat, 05 Jun 1999 02:54:44 GMT, [EMAIL PROTECTED]
>(SCOTT19U.ZIP_GUY) wrote:
>
><snip> <snip> <snip>
>Even if you have personal objections to that style, why wont
>you put your objections to one side and keep everybody
>happy by writing scott19u.zip in that style.
>
I truely belive I wrote it in the style best for someone to look
at it. IF I started adding more comments by there very nature
they would be incomplete inaccuarate and misleding.
Look how many seperate times I explained what zz was in
those few minor lines of code.
Also the pointer in. You know it was not to the first location
of memory. INstead of trying to see how it is used you say
it is wrong and I should have the pointer start at the first
loctaion of that memory block. This is not the kind of thing
I would change in a rewrite because I think I did it the most
straight forward way.
>With 30years experience you *must* know what we mean.
>Why wont you just emulate that style for once ?
>
>During your 30yrs programming experience, you must
>have come across designs written by other people, that
>you are then expected to code. You *must* know the sort
>of description that people want of your algorithm.
Yes many times I have found long sections of flower code
BS that could be shortened to a few lines.
>
>Why can't you supply such a description for scott19u.zip ?
>
>Is it that deep down, you know that once people actually
>know what your algorithm is, they will see it's many weaknesses ?
>
Actually it is written so that it can be ananlyzed.
>If not, prove us wrong. Take the challenge. Show people
>that you really believe in your algorithm. Describe
>you algorithm in a way people understand, and therefore
>give them chance to analyse it.
>
I am sure many of the people that are bitching never looked
at the code. I am just a fun guy to use as a punching bag.
The code is there. Yes you and a few others don't like it
but what does someone like paul onions actaully think of it
does he find it hard to follow.
>Until you do, the doubters will persitst.
>
Doubters will many persitist because I am different and don't
kiss ass very well. But if you write short messages for parts
you question I will anwser I have anwsered you over and over
but I doubt if I will rewrite the whole thing over with out a better
machine and if I do it will have more bells ans whistles.
>Any handwaving will be ignored.
>
>Can we can safely assume that you have not accepted this simple
>challenge ?
>
Tim I think I have anwsered you question. If you want me to go away
and right in a way people can understand you are wrong that is not
going to happen. If they can't follow what Horst did or the diagrams on
the web page there is not much I can do. I can't teach calculus to some one
who is confused by algebra. Also you and I know my english is so bad
people will not read for understanding and will jump up and down on the
typos as errors in the code. There are those that can code and those that
can write. Writting is not my bag. How many complaing have actaully looked
at my website or looked at the C code that are familiar with C code. Less than
I can count on one hand.
>
>- Tim.
>
>(or should that be Z ? long names ey? who needs 'em?)
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] (Tim Redburn)
Subject: Re: Challenge to SCOTT19U.ZIP_GUY
Date: Sat, 05 Jun 1999 20:40:52 GMT
On Fri, 04 Jun 1999 23:52:27 -0400, [EMAIL PROTECTED] wrote:
<snip>
>Actually it's harder than that. Comments often tell you what the
>_original_ programmer _originally_ intended. The secret to good writing
>(of any kind) is rewriting. Rewriting implies that the intentions of
>the author evolve during the process. Thus the final intentions of the
>author(s) may be arbitrarily far from the original intentions.
>
>A truism of software maintenance (which is mostly software analysis) is
>that the value of comments is often negative. More often than not. The
>cost of persuing a false trail based on the comments is high. It can
>pollute your concept pool long after you've learned better (holographic
>memory effects I suppose).
>
>ThHis explains one of the first rules of maintenance. Delete the
>comments, then study the code. Review the comments (skeptically) later
>to resolve problems and find issues warnings not apparent from the code.
>
>The Grail of good software is self-documenting code. That does NOT mean
>comments.
My comments on comments were in response to Davids comments
on comments, and were only a general statement. (and as a general
statement I stand by it, although I agree that you have some perfectly
valid points as well, but further discussion would be off topic)
Throughout my posts I have tried to avoid specifically requesting
that David put loads of comments in his code. There are one or
two places where a short comment would be helpful, but for the
most part, sensible variable names would be far better.
Please remeber that the purpose of this thread is solely to get
David to provide a clear concise reference to his algorithm.
That way his claims about the security it offers can be verified or
shown incorrect. Most people on this group would rather analyse his
algorithm than his source code, if only they knew what his algorithm
actually is.
It would be far more useful if he could provide a concise accurate
electronic document, that includes diagrams, to explain his algorithm,
then we could ignore his source code altogether.
The reason for the posts to this group about the quality of his source
code, are solely because that is all David is prepared to offer as a
complete reference to his algorithm. If David genuinely
wants others to perform a serious analysis of it, with only the source
code as a refence, then we would expect it to be very easily readable
by human beings.Judging by other posts to this news group, I'm not the
only one who thinks that it's not.
- Tim.
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: what cipher?
Date: 5 Jun 1999 13:46:40 -0700
Ok, I was intrigued by Doug Gwyn's throwaway comment about the security
of the Encyclopedia Britannica system. Thanks to Terry Ritter's help,
I think I've managed to re-create the basic idea of the system.
It's helpful to think of LFSRs as acting on GF(2^n) = GF(2)[x] / p(x),
where p(x) is a primitive polynomial over GF(2) that corresponds to the
the LFSR taps. LFSR states may be viewed as appropriate polynomials of
degree < n, i.e. as field elements.
If we let the initial state by denoted by the field element s, then
stepping the LFSR once gives the state s*x (i.e. stepping = multiply by
"x" in the Galois field). Therefore, stepping j times yields a state
corresponding to the field element s*x^j.
The Encyclopedia Britannica construction has two LFSRs, a n-bit main
register and a k-bit key register. The plaintext is loaded into the
main register, which is stepped a number of times selected by the key
register, and the result is the ciphertext; then the key register is
stepped enough to diffuse the bits around some.
In other words, the encryption of the plaintext s is the ciphertext s*x^j,
where j is selected by generating n bits of output from the key register.
(Assuming I understand everything correctly.)
This construction is easy to break with a known-plaintext attack,
at least for reasonable sizes of n, if the taps to the main register
are known. We note that recovering j from s, s*x^j is just an instance
of the discrete log problem in GF(2^n), and thus can be solved in much
less than 2^n time. (In practice, it seems barely possible to solve
this type of discrete log problem for n=1024 or so; typical values of
n like n=64 or n=128 are trivial to solve.) After we recover a few
j values, we learn the output of the key register, which can then be
easily cryptanalyzed with the Berlekamp-Massey algorithm (since it is
just a single-LFSR system).
Ciphertext-only attacks are not so easy, but might still be available.
One line of attack is to hope to find two encryptions s*x^j, s*x^i of
the same plaintext s, as might happen if s is a fairly-constant header
or is some stereotyped text. In this case, we can compute x^{j-i} =
(s*x^j)/(s*x^i) from the ciphertexts, and then solve the discrete log
problem x, x^{j-i} over GF(2^n) to find the quantity j-i. After a few
known values of j-i are recovered, it seems likely that the key register
can be easily broken, since the j-i values are just the differences of
outputs from a simple single-LFSR system.
Another approach to a ciphertext-only attack is to use a
meet-in-the-middle attack. If the number of likely plaintexts can
be enumerated -- say there are 2^m possibilities -- then we can crack
the system with 2^{(n+m)/2} complexity. The idea is simple: for each
likely plaintext s, we compute s*x^i for i=0,1,..,T-1, and store the
result in a lookup table. I suggest using T = 2^{(n-m)/2}. Next,
when we see a ciphertext t, we compute t/s^{j*T} for j=0,1,..,U-1,
and look for the result in the lookup table. I suggest U = 2^n/T.
This process suggests 2^m possibilities for (s,j); then if k is small
enough, each possibility can be used to immediately suggest a potential
key value which is tested by trial decryption; or alternatively, we may
apply the process to two consecutive ciphertexts, and look for pairs
(s,j) (s',j') such that s' seems likely to follow s. Many variations
on this basic theme are probably possible.
Neither of these ciphertext-only attacks are particularly efficient,
but maybe with more effort better ciphertext-only attacks could be found.
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.
------------------------------
From: Nicol So <[EMAIL PROTECTED]>
Subject: Re: DES Effective Security Q
Date: Sat, 05 Jun 1999 17:18:48 -0400
karl malbrain wrote:
>
> Nicol So <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > While I don't have any problem with the result of Biham and Shamir (that
> > independent subkeys increase the amount of chosen plaintexts needed for
> > differential cryptanalysis only by a very modest amount), I would not
> > interpet it as saying that independent subkeys don't help much.
>
> On reading their book last night, what they say is that their attack is on
> those 16 sub-keys reached through the S-boxes -- not on the original 56
> bits. In other words they weren't that interested in the initial key
> combination selection matricies.
I could be wrong, but I think they assumed the subkey bits to be
independent to simplify their probabilistic argument about the
propagation of differences. But that doesn't mean the required amount
of chosen plaintext pairs are the same for the standard key schedule and
for totally independent subkey bits. If my memory serves me right, you
do need more chosen plaintext pairs if the subkeys are totally
independent.
> > (For the sake of argument, assume that the attack postulated above does
> > exist and it is the best practical attack there is. Further assume that
> > independent subkeys increase its complexity to 2^80 trial encryptions.
> > Under such assumptions, independent subkeys help *a lot*.)
>
> Implementing the <<official>> key schedule is <<more>> complicated than
> distilling 768 key bits instead of stopping at 56. Actually, as Jim G
> notes, B & S give 2^64 chosen plaintexts (trial encryptions) as the maximum
> complexity for differential cryptography. Since it's a 64 bit block cypher,
> I'm not sure that's saying much more.
I think you missed my point. I was trying to argue that since
differential cryptanalysis is not a practical attack, the effect of
independent subkeys on the attack is not what one should be concerned
about. What one should be concerned about is the effect of indepdent
subkeys on *practical* attacks. Since we don't know whether there are
practical attacks substantially better than exhaustive search, we don't
know what the *practical* implications of independent subkeys are.
Consider this (hypothetical) scenario. For the given application,
differential cryptanalysis can be discounted as totally inapplicable.
The best known attack that can be considered practical is exhaustive
search. Now we replace the standard key schedule with a good
pseudorandom generator that expands an 80-bit key to 768 bits. If
exhaustive search remains the best practical attack available given the
new key schedule, an increase in key size *does* bring about a
commensurate increase in security, despite the differential
cryptanalysis results.
Nicol
------------------------------
From: [EMAIL PROTECTED] (John Kennedy)
Subject: Re: Hot on the heels of hushmail....
Reply-To: [EMAIL PROTECTED]
Date: Mon, 31 May 1999 11:52:42 GMT
On Sun, 30 May 1999 15:55:41 GMT, [EMAIL PROTECTED] wrote:
>
>> First of all, they're not showing you the code, there's really no good
>> reason to believe the system is secure. Second, 15 character passwords
>> indicates their not even serious about security.
>I think its good enough to keep your IS department from seeing what's
>in that note you are sending your friend. But I am not even convinced
>it is stored encrypted at the site. I think this is what hushmail was
>referring to when they said much more than SSL.
>
>Who says the 15 character password you type in to decode it stays in
>your machine? How does it know that the password you gave is the
>incorrect key for the message?
They've provided you with the source that runs on your client side.
Verifying the source at ruh time is an issue, but in principle you can
know whether your password is being transmitted.
You could only know if you are getting the right key by comparing
fingerprints, and I don't know that this has been addressed.
If you can't verify the key then they could be reading everything.
>
>Even if secure, one of the things these services do is to collect e-
>mail addresses of people that use their service. I wonder when the
>spams start coming in.
>
>Art Gecko
>
>
>Sent via Deja.com http://www.deja.com/
>Share what you know. Learn what you don't.
--
John Kennedy
--
The causal world imposes a nonarbitrary distinction between detecting in one's visual
array
the faint outline of a partly camouflaged stalking predator and not detecting it
because of
alternative interpretative procedures. Nonpropagating designs are removed from the
population, whether they believe in naive realism or that everything is an arbitrary
social
construction.
(Tooby and Cosmides, in _The Adapted Mind_, Barkow,
Cosmides and Tooby, editors )
=======
Best Anarchy Links:
David Friedman -> http://www.best.com/~ddfr/
Niels Buhl -> http://www.math.ku.dk/~buhl/
Billy Beck -> http://www.mindspring.com/~wjb3/promise.html
========
------------------------------
** 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
******************************
