Cryptography-Digest Digest #454, Volume #14 Sun, 27 May 01 06:13:01 EDT
Contents:
Re: Mainstream Quasiprobabilities and Memory Theory - Doctorow (SCOTT19U.ZIP_GUY)
Re: Comparison of Diff. Cryptanalysis countermeasures (David Wagner)
Re: Good crypto or just good enough? ("Douglas A. Gwyn")
Re: Good crypto or just good enough? (Paul Crowley)
Re: Good crypto or just good enough? ("Douglas A. Gwyn")
Re: Getting back to the self-study Analysis ("Douglas A. Gwyn")
Re: survey ("Douglas A. Gwyn")
Re: Medical data confidentiality on network comms (Roger Fleming)
Re: Newbie question about algo (Roger Fleming)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Mainstream Quasiprobabilities and Memory Theory - Doctorow
Date: 27 May 2001 05:09:51 GMT
[EMAIL PROTECTED] (Osher Doctorow) wrote in
<9epvt4$9dk$[EMAIL PROTECTED]>:
>From: Osher Doctorow [EMAIL PROTECTED], Sat. May 26, 2001 9:08PM
>
>It doesn't necessarily seem mean, especially if you could explain to me
>what you mean by *to whom are you addressing these? What new results
>are you discussing?* I will take a guess and suppose that you either
>(a) have not been following my previous posts, or (b) cannot see how
>this post ties in with previous posts, or both. In that case, the
>easiest way is to look up my previous posts, including ones on
>sci.physics, sci.physics.relativity, sci.optics, sci.polymers,
>sci.energy, sci.engr.control, sci.math, sci.math.stat, etc. Or look up
>abstracts of 54 of my papers at http://www.logic.univie.ac.at, Institute
>for Logic of the University of Vienna (select ABSTRACTS, then BY AUTHOR,
>then my name). Or read my paper in B. N. Kursunuglu (Ph.D. Cambridge
>University under Paul Dirac), S. L. Mintz, and A. Perlmutter (Eds.)
>Quantum Gravity, Generalized Theory of Gravitation, and Superstring
>Theory-Based Unification, Kluwer Academic/Plenum: N.Y. 2000.
>
>Several possibilities also occur to me. If you do not see why you
>should go to the trouble of looking up those papers and wish me to
>summarize things so that you can decide, well, perhaps all is fair in
>love and war. I am talking about the entanglement aspect of quantum
>cryptography and quantum computers. Memory (M) Theory, which I have
>been developing in the past year as a generalization of the paper in
>Kursunuglu et al, uses spherical harmonics, spherical
>expansion/contraction, radiation, among its main tools and objects, and
>I am showing how quasiprobability - a very deep approach - is coming up
>with some similar results and methods. I said that in my contribution.
>
>The brevity of your message, *Why are you doing this?* also leads me to
>ask: *How are you doing anything with messages of such cryptic brevity?*
>But then, I suppose you have different standards when addressing one of
>the Patriarchs of Science or of the Computer World. As long as you are
>asking yourself the same questions (how often, by the way?), perhaps it
>is all a good learning experience and for the better.
>
>Osher Doctorow Ph.D.
>Doctorow Consultants
>Formerly California State Universities and Community Colleges (still
>intermittently teaching)
>
I am sorry you were treated so badly by Tommy boy. He is kind
of the attack dog for the so called crypto ellite. They really
don't want new ideas or views. They seem to have made up there
mind the future of cyrpto is to be sinple high speed low complexity
methods. I for one belive that quantum computers are already here.
And that crypto should be desinged as if the enemy is using a
specailly constructed quatum computer to break the code. The
truely sad thing is that PGP is so bad that even when the public
key mode of encryption is not used. The main method uses such
poor compression and encryption methods that even if a pure random
file was encrypted. Then only one key could be used that would
decrypt the message. The bad keys may easlily be rejected as not
leading to a file that could be encrypted. If this is not a
recipe to making it easy for breaking using quantum methods I
don't know what is.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
made in the above text. For all I know I might be drugged or
something..
No I'm not paranoid. You all think I'm paranoid, don't you!
------------------------------
From: [EMAIL PROTECTED] (David Wagner)
Subject: Re: Comparison of Diff. Cryptanalysis countermeasures
Date: 27 May 2001 05:10:33 GMT
>David Wagner wrote:
>> In any case, from my point of view, the main attraction of key-dependent
>> S-boxes is *not* that they stop differential cryptanalysis. We already
>> know how to build ciphers that stop differential cryptanalysis cold.
>
>Would you be willing to expound on this if you're thinking of a method
>of thwarting D.C. that hasn't already been discussed in this thread?
This is well-discussed in the literature, and many modern ciphers
come with an argument that they resist differential cryptanalysis.
For instance, one of the central features of Matsui's papers on
MISTY is his description of how the design ensures that differential
and linear approximations will die out very quickly with only a few
rounds. Of course, each cipher can be viewed as having its own way
of preventing differential cryptanalysis, so you can pick any one you
like and see how it prevents differential attacks; although there are
some commonalities, it's not as if there is "One True Way" of stopping
differential cryptanalysis.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Sun, 27 May 2001 05:31:53 GMT
Tom St Denis wrote:
> Technically 3DES is not DES though. It's incorrect to assume it
> inherants all the *trust* of DES ...
It's not hard to see that 3DES is no less secure than DES.
Whether it is *much* more secure is, so far as I know, an
open question. (Since it uses more key bits in additional
series stages, it must be at least *slightly* more secure.)
The incontrovertable fact is that 3DES is not feasibly
brute-force searchable (yet) while DES is, so *everybody*
(that matters) knows how to crack DES, but *not* everybody
knows how to crack 3DES.
------------------------------
Subject: Re: Good crypto or just good enough?
From: Paul Crowley <[EMAIL PROTECTED]>
Date: Sun, 27 May 2001 05:34:50 GMT
Tom St Denis <[EMAIL PROTECTED]> writes:
> Would you settle for crypto that is "just secure enough" or "is as
> secure as we know how to make it". Both within reason.
That depends on the costs. In general, people don't use crypto at
all, so I think it's worth sacrificing all sorts of security to
convenience; for example, it's better to build an encrypted tunnel
vulnerable to man-in-the-middle attack than to have no encryption at
all, especially if we can make it so invisible to users that it
doesn't give them a false sense of security...
But there's hardly ever a good reason not to use a truly strong cipher
- for example, Rijndael rather than DES - because the costs are the
same.
--
__ Paul Crowley
\/ o\ [EMAIL PROTECTED]
/\__/ http://www.cluefactory.org.uk/paul/
"Conservation of angular momentum makes the world go around" - John Clark
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Good crypto or just good enough?
Date: Sun, 27 May 2001 05:37:06 GMT
"SCOTT19U.ZIP_GUY" wrote:
> The NSA wants people to use [Rijndael] for several years.
I'm sure the NSA would be happiest if everybody used the *same,
standard* cryptosystem, only because their cryptanalysts could
concentrate resources on cracking just the one system instead
of spreading them thinly across numerous commonly-used systems.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Getting back to the self-study Analysis
Date: Sun, 27 May 2001 05:45:11 GMT
Tom St Denis wrote:
> ... I can't figure out how to exploit the linear relationship
> A xor K = B
> A' xor K = B'
Exploit how? From these the only exploitation possible is to use
A xor A' = B xor B'
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: survey
Date: Sun, 27 May 2001 05:51:40 GMT
One useful lesson I learned decades ago was that a typical technical
paper can have its verbiage cut in half and, if properly done, the
result conveys all the information that the original did. Try it!
------------------------------
Crossposted-To: comp.security.misc
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Medical data confidentiality on network comms
Date: Sun, 27 May 2001 06:22:03 GMT
Kathy, you might also want to have a look at
http://www.cl.cam.ac.uk/users/rja14/#Med
Ross Anderson is a renowned cryptographer, and the link above leads to several
interesting resources about medical information confidentiality, including a
paper Ross wrote that critiques (well shreds, really) a proposed British
government standard.
------------------------------
From: [EMAIL PROTECTED] (Roger Fleming)
Subject: Re: Newbie question about algo
Date: Sun, 27 May 2001 08:23:27 GMT
[EMAIL PROTECTED] (Martin Kiewitz) wrote:
>Hi !
>
>I'm somehow a newbie to cryptology and i'm just building some stream
>encryption algorythmn.
First, it's great fun to invent your own algorithms and try to attack them,
but for serious purposes it is rarely a good idea. Even if someone on this
group hadn't noticed any problems with your proposal, the 30 minutes of
examination it received is hardly equivalent to the years of expert analysis
that have gone into something like SSL.
>I don't want flames, please. I'm posting this, so other people can
>post their opinions about it.
You won't get any flames - yet. Be aware, however, that there is a strange
habit for inventors to feel as if attacks on their inventions are somehow
personal, even though you asked others to find such attacks, as a favour. This
is extremely rude to those who freely gave their time to help the inventor,
and results in a lot of newbies thinking they are the victims of an unprovoked
flame war, when in fact they are themselves the sole cause of the trouble.
Also, as soon as you see some attacks on your system, your instinct will be to
patch the algorithm and publish the new version, then repeat the process until
the algorithm has become complicated enough no-one wants to examine it in
their spare time, and the inventor claims to have produced a strong algorithm.
Doing so is extremely dishonest, since others have done all the real work.
>I want to encode a duplex-stream (named pipes, tcp-connection, etc.)
>using a really fast and safe algorythmn.
Not surprisingly, others have had this problem before, and already solved
it. Look for the openssl library, and you will find nearly all the code
already written for you.
>Handshaking is done using PGP Public Key.
>The server sends its System-Key to the client.
>Client checks key by proofing signature with Super Key.
>Now client encodes LoginData & Crypto Hash using Public Key.
>Client sends that paket to server.
>Server decrypts LoginData & Crypto Hash with its own secret key.
>
>Now server sends unencrypted (raw) success of login. (that's done, so
>no byte guessing can take place).
>Server sends terminal operations, till actual interactive use needs to
>be done by client. (actually till Server thinks Crypt is needed).
OK, there are a couple of problems with this.
First, it's vulnerable to replay attacks. If I watch some user successfully
logon, and record the packet he sent, I can later logon to the server by just
sending the same packet again. This logs me on, using the same encryption
table as the user's last session. I can repeat commands he sent last time
(might be useful sometimes), send random commands (he will get blamed if it
causes any damage), or - if I managed to break his last encryption table -
control the machine using his ID. All this without even having to guess his
password or username, never mind breaking the public key stuff.
Second, there is no verification of the server to the user. Anyone could send
you the server's public key, and you won't know you're talking to an imposter
until the server is forced to encrypt some data and you notice that it's
gibberish. If the "user" is an automatic process, it might never notice. If
the server can always choose not to encrypt data (which you suggest might be
the case), even a human will never notice. So, it's a good idea to,
immediately after the key exchange, do a transaction that proves each side
knows the key.
Third, you've completely omitted the important detail of how all this data
will be structured. This is quite an important detail as I can think of
several potent attacks if it's done badly. Since you are sending over 2kB of
data, obviously there will be several public key encrypted blocks (probably at
least 8). Suppose you do the obvious thing, putting the login details first
then immediately fill up the first block with "Crypto Hash" stuff, then put
the rest of the "Crypt Hash" in subsequent blocks. If you do that, though, the
attacker can replay the first block (login details plus, say, 200 bytes of
hash table) and choose all the other hash table entries himself. Now, without
any cryptanalytic effort, he's logged on and already knows 90% of the "Crypto
Hash". Alternatively, if he can cryptanalyze the first 200 bytes of the
"Crypto Hash" then - even if he can't get the rest - he can now mount an
off-line dictionary attack on your password.
Finally, you don't discuss how you create the "Crypto Hash", which is pretty
important. (Later you say 'both are "true" randomized numbers'. Do you mean
you use a hardware random number generator to generate 2 kB (16, 384 bits) of
truly random data for each logon? This would be incredibly slow, and is a
wasted effort since Scott Fluhrer's attack shows that all the initial
randomness quickly leaks away, and is replaced solely by randomness from the
input stream.)
There may be other problems; these are just a few I noticed straightaway.
Designing authentication and key exchange potocols is quite tricky; you are
well advised to use an existing, proven one - such as SSL!
>Now my own crypt algo looks like this:
>
>In and Out Stream, both have 2Kbyte Hash, both are generated by client
>and both are "true" randomized numbers.
>
>I suppose: CurPos = 0 (at begin of en/decryption)
>
>To encode:
> 1. EncodedChar = OrgChar xor Hash[CurPos]
> 2. Hash[CurPos] = Hash[CurPos] xor EncodedChar
> 3. CurPos = CurPos+OrgChar
> 4. CurPos is cut down to 2k range
> 5. Encode further data
>
>Decoding is performed accordingly.
>
>Is this algo good ? Is it breakable ?[...]
OK,Scott Fluhrer already pointed out a very serious problem, but I noticed a
neat little demonstration that shows just how severe that problem is. Because
of the problem that Scott noticed, if an input character is a 0, then the next
character is always output in plaintext!
Suppose the input stream is in Unicode but the Latin character set. Then every
second character is a 0, so all the significant characters are output in
plaintext!!! Each plaintext character is separated by one completely exposed
table value so after such a Unicode input is maintained for about 2kb, the
attacker trivially can see the entire contents of the table, and continue
decrypting even if further input is more irregular.
I think you will agree that a cipher which, when given a plaintext with
certain commonplace structures, does no encryption at all but instead outputs
the plaintext _and_ the key, has a fatally serious flaw. Don't tell yourself
"well, I just won't use Unicode"; the problem is much further reaching than
that, this is just a nice demonstration of it.
Have a look at RC4. It's unencumbered (except the name, which is trademarked),
only about as complicated as your existing cipher, about as fast, uses less
memory, and is much stronger. It is also built into - you guessed it,
openssl.
------------------------------
** 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
******************************
