Cryptography-Digest Digest #182, Volume #9 Wed, 3 Mar 99 23:13:04 EST
Contents:
Re: Define Randomness ("Trevor Jackson, III")
I updated my algorithm and would like some analysis ([EMAIL PROTECTED])
Re: Define Randomness (Michael Sierchio)
Re: Elliptic Curve Cryptography (Michael Sierchio)
Encrypting Images Using Fractals (gary huntress)
Enigma Device needs testing. (Warkior)
Re: Elliptic Curve Cryptography (Rayees Shamsuddin)
Re: need simple symmetric algorithm (BORIS KAZAK)
Re: Elliptic Curve Cryptography (DJohn37050)
Re: Common meaning misconception in IT, was Re: Unicity of English, was Re: New
high-security 56-bit DES: Less-DES ([EMAIL PROTECTED])
----------------------------------------------------------------------------
Date: Wed, 03 Mar 1999 20:23:46 -0500
From: "Trevor Jackson, III" <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
Terry Ritter wrote:
> On Tue, 02 Mar 1999 00:14:28 -0500, in <[EMAIL PROTECTED]>,
> in sci.crypt "Trevor Jackson, III" <[EMAIL PROTECTED]> wrote:
>
> >[...]
> >An issue worth addressing is the way to define insecurity for a cipher whose
> >virtue is not based on work factor, but on undecidability. The classic vernam
> >cipher does not have a work factor as far as I understand the term.
>
> That sure sounds wrong to me. The work factor is the effort involved
> in resolving the internal RNG state given known-plaintext.
If the RNG is built by sampling some natural process there is no internal state to
deduce. In the case of a reusable key (non OTP) the work factor is the cost of
producing the information necessary to decipher messages other then those that are
input to the analysis work. In the case of a non-reusable key (OTP) the analysis does
not produce information that allows the decryption of other messages. Thus I cannot
see the applicability of the work factor concept.
>
>
> >Yet it must
> >admit degrees of insecurity.
>
> Sure. There is different security in different RNG designs.
>
> >For instance, if I use each key exactly twice. I
> >have theoretically compromised my security.
>
> Absolutely.
>
> >But using each key exactly 1,000
> >times would be a more serious weakness. Yet by your standards you would consider
> >both systems insecure; the binariness imples they are *equally* insecure.
>
> I would say that one cannot get more compromised than compromised. If
> by "more serious" you imply that by good fortune The Opponent did not
> pick up on the earlier error, you have just accepted what we demand a
> cipher not do. We insist a cipher *prevent* giving The Opponent
> access, no matter what courses he takes. The Opponents will not tell
> us that they have failed to pick up an error -- so we must assume that
> they used it. If it is sufficient to wish and hope The Opponent has
> not spotted a weakness, we might as well wish and hope that The
> Opponent is not looking at us at all, in which case why bother with
> cryptography?
No. There are weaknesses that reduce the workfactor below that of brute force without
eliminating it completely. Thus an attack that reduces a key space of 2^56 to an
effective space of 2^48 "compromises" the cipher, but incompletely.
The binary approach to security is probably not the best because security is only a
defensive cost. I might be willing to use a compromised (2^48) version of a normal
(2^56) cipher in special circumstances for instance, real time process control where
the entire process last less than 60 seconds. Or 10 seconds. Or 2 seconds.
Jus that fact that we can speak of stronger or weaker methods implies that the binary
standard is too simplistic.
>
>
> >>[...]
> >> Sure, if somebody gets the key, they are in. But the issue in the
> >> above paragraph was: "why not use an ordinary cipher to protect the
> >> OTP key"? The answer is that we then depend upon the strength of the
> >> ordinary cipher for security, which reduces the hoped-for security to
> >> about that of the ordinary cipher. And that means we might as well
> >> use the ordinary cipher -- which is far easier to use -- and forget
> >> about the OTP.
> >
> >Only in the case of trivial application mechanisms (e.g., straight XOR). This is
> >similar to the conclusion that PRNGs are useless for ciphers because a simple XOR
> >is easily reversible, and once the key stream is visible it can be analyzed and
> >then predicted.
> >
> >Non-trivial application mechanisms eliminate these straman arguments against
> >PRNGs, and, I believe, against the Vernam system.
>
> Surely you don't imagine that I have forgotten my own original work on
> Dynamic Substitution combining which does just this? But when was the
> last time you saw anyone (other than me) recommend using a serious
> nonlinear combiner with state for an OTP? That could be a Latin
> square, or Dynamic Substitution, or, presumably, something else. But
> everybody insists that XOR is good enough for them because an OTP is
> "proven absolutely secure." Right.
>
> Nevertheless, for analytical purposes, it is worth assuming that The
> Opponents have penetrated one level of strength so we can discuss what
> strength means in the other level. We can just build an RNG and a
> combiner and hope neither exposes the other, or we can try to see how
> well each would stand on their own.
Agreed. Many analyses of PRNG stream ciphers conclude that they are useless because
the RNG state can be deduced given enough of the key stream, and the key stream is
available once some plaintext is known. Well the trivial part of these strawman
systems is the straight through XOR not the PRNG.
The same applies to some of the arguments you have used against OTPs. Let's not
trivialize other parts of the system and then complain how easy the system is to
break!
>
>
> >[...]
> >I suppose they are pretty tightly bound. Another property worth cataloging as an
> >index is the portion of the cipher at which the analysts "inserts his wedge" as
> >it were. There is a logical starting point for most attacks, often a particular
> >operation that is vulnerable to analysis.
>
> I think in most cases this is what the "information exposure" conveys.
> Or were you thinking of something different? How about an example?
>
> >[...]
> >Yes. Exhaustive testing is rarely useful. We need a set of tests whose results
> >can be extrapolated over larger regions than those tested. I believe a MITM
> >style of testing may be possible. Given a cipher a theoretician might be able to
> >define a representative set of tests whose results scale up to cover the entire
> >system. I speak here not of the keyspace, but of round counts, S-box sizes,
> >etc. Scalable ciphers will provide this capability. One we currently lack.
>
> Allow me to just point out that *all* of my modern cipher designs are
> scalable. I have yet to see a stampede to my technology.
Are your design scalable at the source code editor level, sompile time constants,
install/config-time constants, or by the user?
>
>
> >> And all this depends upon *having* a weakness test! In my opinion,
> >> such a test must find *every* *possible* weakness, and must do so with
> >> absolute perfection. I would be very, very dubious about trying to
> >> estimate the "strength" of a cipher on the basis of a "strength" test
> >> which could miss any number of innovative attacks.
> >
> >Try to avoid making test perfection into a grail.
>
> There are two levels to experimental cipher analysis: 1) the ability
> to find "weakness," and 2) the statistical sampling required to
> achieve an expectation of the desired level of strength. Here (2) is
> inherently imprecise; we understand it in a statistical context.
> But (2) *depends* upon (1), and the only way (2) works, as far as I
> can see, is the assumption that (1) is correct.
>
> Again, a "weakness" test which only finds *some* weaknesses is not
> sufficient to certify a cipher against arbitrary attack.
I have no need to certify a cipher against an arbitrary attack. As discussed above
this is impossible. A test that reliably detects some fraction of the possible
defects would be useful.
>
>
> Of course if we can convince The Opponents to play fair and only use
> the attacks we specify, then we don't need to consider other attacks.
> Maybe there oughta be a law....
>
> >I thought we had concluded
> >above that perfect testing was not a useful concept. Consider that cryptology is
> >a very new science (if it is a science; I tend to think not). There is great
> >value in a compendium of all known attacks even if the collection is provably
> >incomplete.
>
> I think this is largely what we see in the literature and in various
> crypto texts.
>
> >The reason I find merit in this apparently inadequate tool is contained in the
> >testing "correlation of forces". A weak cipher is probably going to fail many
> >tests. A strong but flawed cipher may still fail multiple tests. A slightly
> >imperfect (shall we use the gemologists scale: very very slightly imperfect?) may
> >fail only one test.
>
> I would still say that compromise is compromise. Even one fault is
> sufficient to call the cipher broken academically, and to use another
> cipher in practice.
>
> Worse than that, we expect that most ciphers will fail no *tests* at
> all. What they may fail is attack by Opponents, which we will not
> know about, and it matters not how many attacks would have succeeded.
>
> >A cipher that fails no test may still contain a flaw, but as the science matures
> >it will become harder and harder for an adversary to detect the flaws that the
> >assembly of tests fail to detect.
>
> There is no way we can know this or assume that future attacks need be
> harder. Those guys are smarter than we are, are better funded, and
> have more experience, equipment, and time. They may have a shortcut.
>
> An attack need not be harder at all if The Opponent has a break we
> don't know about.
>
> >In the limit we'll find that the analytic
> >effort required to find a flaw may have such a high work factor that the cipher
> >may have "security through subtlety".
>
> There is no reason to assume that attacks we don't know about will be
> more difficult than the attacks we do know about. In fact, every new
> attack is easier than the one it replaces.
I didn't say that the attack was harder. I saind that *finding* the attack will be
harder.
>
>
> >Extrapolating from current, labor-intensive attacks may be like extrapolating New
> >York City in 1900. The prediction was that by 1950 everyone in the world would
> >have to be an NYC telephone operator, and the place would be covered by a layer
> >of horse manure 50 feet thick. Automated testing would permit automated cipher
> >mutation. Metaphorically, everyone in the world has to work for the NSA, and
> >every message sent has 6.023e23 BCC recipients.
>
> Current ciphers simply offer no confidence at all that only certain
> attacks, certain classes of attacks, or only attacks of given minimum
> effort will succeed. It is entirely plausible that new, innovative,
> comparatively-simple attacks will be found for any cipher at some time
> in the future. It is also plausible that The Opponents will have been
> exploiting that attack almost from cipher introduction.
>
Well, reluctantly, yes. By this attitude the person with the least knowledge
regarding the security of a cipher is the cipher designer/user. This pessimism is
probably appropriate.
------------------------------
From: [EMAIL PROTECTED]
Subject: I updated my algorithm and would like some analysis
Date: Thu, 04 Mar 1999 00:38:21 GMT
First off, thanks again for those who replied.
I updated the algorithm, so that instead of summing the values needed for my L
and S I perform a checksum, so they are more position dependant.
Check it out at:
http://members.tripod.com/~tomstdenis/e.c
If you have any questions, flames, suggestions, or whatever, please email me
or the group. I would love to read what you have to say.
Thanks,
Tom
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Define Randomness
Date: Wed, 03 Mar 1999 17:42:07 -0800
Reply-To: [EMAIL PROTECTED]
Terry Ritter wrote:
> ...
> It may be that few of us think an OTP will provide sufficiently better
> security to be worth the effort and risk of key-generation, transport,
> and storage. Because of increased risks, the overall security from
> using a realized OTP might even be *less* than (properly!) using some
> other modern cipher. If so, the OTP is hardly "best," even *if* we
> assume that the cipher per se cannot be "broken."
So it's not "price" but "cost." It is possible to deploy secure OTP,
but the costs are high. I wasn't the one preaching its virtues, I was
objecting to the logic of your argument in your previous post. Amid the
sometimes high (apparent) noise level in this group, I look forward to
your contributions.
I myself think a lot of my dripping faucet RNG -- probably gets about
20 bits of entropy per minute. ;-)
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Cryptography
Date: Wed, 03 Mar 1999 17:49:13 -0800
Reply-To: [EMAIL PROTECTED]
nobody wrote:
>
> I am searching for some "down-to-earth" information about elliptic curve
> cryptography.
I don't know about "down to earth." Any understanding will require a working
knowledge of algebraic number theory. Some refs. Perhaps no. 3 is what
you're looking for.
LOC Catalog Info
Author: Koblitz, Neal, 1948-
Title: A course in number theory and cryptography / Neal
Koblitz.
Published: New York : Springer-Verlag, c1987.
Description: 208 p. : ill. ; 24 cm.
Series: Graduate texts in mathematics ; 114
LC Call No.: QA241.K672 1987
Dewey No.: 512/.7 19
ISBN: 0387965769 : $29.80
Notes: Includes bibliographies and index.
Subjects: Number theory.
Cryptography.
Control No.: 87016645 //r902
----
Author: Koblitz, Neal, 1948-
Title: Introduction to elliptic curves and modular forms
/ Neal Koblitz.
Published: New York : Springer-Verlag, c1984.
Description: viii, 248 p. : ill. ; 25 cm.
Series: Graduate texts in mathematics ; 97
LC Call No.: QA567.K63 1984
Dewey No.: 516.3/5 19
ISBN: 0387960295
Notes: Bibliography: p. [240]-243.
Includes index.
Subjects: Curves, Elliptic.
Forms, Modular.
Number theory.
Control No.: 84010517 //r92
----
Author: Rosing, Michael, 1954-
Title: Implementing elliptic curve cryptography /
Michael Rosing.
Published: Greenwich : Manning, c1999.
Description: xiv, 313 p. : ill. ; 23 cm.
LC Call No.: QA76.9.A25R66 1999
Dewey No.: 005.8/2 21
ISBN: 1884777694 (pbk. : alk. paper)
Notes: Includes bibliographical references and index.
Subjects: Computer security.
Data encryption (Computer science)
Curves, Elliptic -- Data processing.
Control No.: 98040461
------------------------------
Date: Wed, 03 Mar 1999 20:09:58 -0500
From: gary huntress <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Encrypting Images Using Fractals
Hi Everyone,
I've been playing with an image encryption algorithm that I think is
pretty interesting. I'd be interested in hearing any feedback about
it. In a nutshell, I do the following to encrypt and decrypt an image:
1) format the plaintext image as a square matrix
2) generate a square encyption matrix of equal size using a key
generated from a fractal (chaotic) equation
3) encrypt the plaintext with simple matrix multiplication and
send to the recipient
4) The encryption matrix is not sent to the recipient, but
rather the fractal parameters are sent via a secure means.
5) The recipient regenerates the encryption matrix using the
fractal key, inverts the matrix, and decrypts the encrypted data to
obtain the plaintext.
As an example, I encrypted and decrypted a 400x400 pixel image. I used
a generic mandelbrot fractal to generate the 400 x 400 encryption
matrix. In order to regenerate this encryption matrix, it is only
necessary to store the fractal parameters (like the mandelbrot loop
count, initial condition, and coordinates of the corners). Obviously
there are implementation issues, like ensuring that the encryption
matrix is invertable, but that isn't too difficult.
I dont make any claims that this is a method of "stronger" encryption,
because I have no means to determine the strength of an encryption
algorithm. Rather, I think that it is an "efficient" method, in that
the sender only had to provide the fractal key parameters, not the
significantly larger encryption matrix.
Fractals and encryption is a fascinating topic! Is there active
research in this area?
Regards,
Gary Huntress
[EMAIL PROTECTED]
------------------------------
From: Warkior <[EMAIL PROTECTED]>
Subject: Enigma Device needs testing.
Date: Thu, 04 Mar 1999 01:52:18 GMT
Hey, I've recently created a scrambling routine similar to the WWII Enigma
device (at least what I understand of it) and need some people to check it
out, comment on it's "crackability", give me any suggestions, ...
The BASIC code for it and a sample scrambled file is found at:
http://www.geocities.com/SiliconValley/Chip/8355/games.html
If you tell me what you think I'd appreciate it. Thanx
WarkenSoft Productions
http://www.bigfoot.com/~WarkenSoft
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: Rayees Shamsuddin <[EMAIL PROTECTED]>
Subject: Re: Elliptic Curve Cryptography
Date: Wed, 03 Mar 1999 19:13:53 -0800
Have a look at
http://www.certicom.com/
There are some whitepapers on ecc as well as a background algebra and ecc
tutorial. ECC cant be taught simpler than this.
regards
rayees
http://www.ece.orst.edu/~rayees
[EMAIL PROTECTED]
Michael Sierchio wrote:
> nobody wrote:
> >
> > I am searching for some "down-to-earth" information about elliptic curve
> > cryptography.
>
> I don't know about "down to earth." Any understanding will require a working
> knowledge of algebraic number theory. Some refs. Perhaps no. 3 is what
> you're looking for.
>
> LOC Catalog Info
>
> Author: Koblitz, Neal, 1948-
> Title: A course in number theory and cryptography / Neal
> Koblitz.
> Published: New York : Springer-Verlag, c1987.
> Description: 208 p. : ill. ; 24 cm.
> Series: Graduate texts in mathematics ; 114
> LC Call No.: QA241.K672 1987
> Dewey No.: 512/.7 19
> ISBN: 0387965769 : $29.80
> Notes: Includes bibliographies and index.
> Subjects: Number theory.
> Cryptography.
> Control No.: 87016645 //r902
>
> ----
>
> Author: Koblitz, Neal, 1948-
> Title: Introduction to elliptic curves and modular forms
> / Neal Koblitz.
> Published: New York : Springer-Verlag, c1984.
> Description: viii, 248 p. : ill. ; 25 cm.
> Series: Graduate texts in mathematics ; 97
> LC Call No.: QA567.K63 1984
> Dewey No.: 516.3/5 19
> ISBN: 0387960295
> Notes: Bibliography: p. [240]-243.
> Includes index.
> Subjects: Curves, Elliptic.
> Forms, Modular.
> Number theory.
> Control No.: 84010517 //r92
>
> ----
>
> Author: Rosing, Michael, 1954-
> Title: Implementing elliptic curve cryptography /
> Michael Rosing.
> Published: Greenwich : Manning, c1999.
> Description: xiv, 313 p. : ill. ; 23 cm.
> LC Call No.: QA76.9.A25R66 1999
> Dewey No.: 005.8/2 21
> ISBN: 1884777694 (pbk. : alk. paper)
> Notes: Includes bibliographical references and index.
> Subjects: Computer security.
> Data encryption (Computer science)
> Curves, Elliptic -- Data processing.
> Control No.: 98040461
------------------------------
From: BORIS KAZAK <[EMAIL PROTECTED]>
Subject: Re: need simple symmetric algorithm
Date: 4 Mar 1999 03:19:39 GMT
Reply-To: [EMAIL PROTECTED]
Daniel Feurle wrote:
>
> Hi everyone!
>
> I am a student a in Database Systems Class at Technical University in
> Vienna. There I do a project in engineering a simple DB application. In this
> application I have a small table with products and its price. Now I want to
> decrypt only the priceinformation field to the table and then to access to
> this information only by my application. I need this becouse nobody should
> be able to read this Information by accessing only the DB.
> Therefore I need a simple symmetric algorithm to decrypt and encrypt this
> number field which is only a 16-bit integer number.
>
> Can anyone help me, or send me some Information about that.
> I would really appreciate it,
> thanks,
> Dan.
=======================
The problem seems very straightforward.
If your database is just a table, then the "coordinate" of
your number field is uniquely determined as a combination of row
and column numbers.
In this case:
1. Take any block cipher of your choice (DES, IDEA, BLOWFISH...)
2. Choose a key to use with this cipher.
3. Put together the row number and the column number of the
number field you wish to encrypt (for example 0127 0012).
4. Use this number as plaintext for the cipher, encrypt it and
produce the ciphertext.
5. Take the first 2 bytes of this ciphertext and XOR them with
your 16-bit number field. DONE !
6. Decryption is the same as encryption.
This way you will encrypt each number field differently, you will
have only 1 key to remember, the encryption procedure will not depend
on the content of the field, only on its "coordinates".
Respectfully BNK
------------------------------
From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic Curve Cryptography
Date: 4 Mar 1999 03:36:10 GMT
Also check out IEEE P1363. It has a lot of good info on ECC. Search on IEEE
P1363 on any search engine.
Don Johnson
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Common meaning misconception in IT, was Re: Unicity of English, was Re:
New high-security 56-bit DES: Less-DES
Date: Thu, 04 Mar 1999 03:50:23 GMT
In article <[EMAIL PROTECTED]>,
Bryan Olson <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] wrote:
> > John Savard wrote:
> > > Language statistics, as they become more detailed, are simply
> > > approximations to a human writer - or reader.
> | > Hence, the redundancy of
> | > English text can only be approximated through language statistics,
> | > which give a _lower bound_ for the actual redundancy.
>
> > ...in letter-frequency or even in word-frequency or phrase frequency -- but
> > NEVER in sense. The Information theory definition of entropy and the derived
> > definitions of conditional entropy and unicity have nothing to do with
> > meaning, sense or knowledge as I explained in the message.
>
> John Savard's observation is entirely correct.
Yes ...in letter-frequency or even in word-frequency or phrase frequency --
but NEVER in sense. Which is the subject here -- letter frequency attacks on
cryptograms do not at all discern whether the message makes sense. As I
explained RE the unique solution to "Maine Drag" riddle.
But, it is no surprise that you are again confusing issues before this list
-- instead of learning things first. It is fine to ignore basic facts and
perhaps you can learn a lot more just by reading and asking questions. I
believe you will receive a lot more attention and much improved answers once
you start to truly communicate. Just trust yourself a bit more, in a fair
dialogue -- if you do not understand something -- ask. By the current odds,
as in the archives, if you do not understand something then most ptobably the
problem lies at your side... so, give yourself a chance.
Ed Gerck
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
** 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
******************************
