Cryptography-Digest Digest #716, Volume #12 Tue, 19 Sep 00 11:13:01 EDT
Contents:
Re: Double Encryption Illegal? (WARNING: GERMAN) (Runu Knips)
Rik Kershaw-Moore/Intl/Herman Miller is out of the office. ("Rik Kershaw-Moore")
Re: Simple hash function (Anders Thulin)
Re: Optimization for speed question. ("Tor Rustad")
Re: Optimization for speed question. ("Tor Rustad")
Re: CDMA tracking (was Re: GSM tracking) ("H. Ellenberger")
BUG in CryptLib 3.0. Is there a fix? ([EMAIL PROTECTED])
Re: Questions about how to run a contest (Sylvain Martinez)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an alternative
intorduction] ("Abyssmal_Unit_#3")
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an (JCA)
Re: A conjecture - thoughts? (John Savard)
Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption (John Savard)
Re: More Bleh from a Blahish person. ;) (Zulfikar Ramzan)
Re: Hamming weight (Terry Ritter)
----------------------------------------------------------------------------
Date: Tue, 19 Sep 2000 14:28:19 +0200
From: Runu Knips <[EMAIL PROTECTED]>
Crossposted-To: comp.databases.oracle
Subject: Re: Double Encryption Illegal? (WARNING: GERMAN)
Mok-Kong Shen wrote:
>
> Runu Knips wrote:
> >
> > Mok-Kong Shen wrote:
> > > Tom St Denis wrote:
> > > > Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> > > > > Tom St Denis wrote:
> > > > > > [EMAIL PROTECTED] (Paul Schlyter) wrote:
> > > > >
> > > > > > > So you're claiming that triple-DES is no more secure than single-
> > > > > > DES ???
> > > > > >
> > > > > > Read my message. Geez. I said "double" encryption is not the way
> > > > to
> > > > > > go about added security.
> > > > >
> > > > > Could you be more explicit and explain why? Are you
> > > > > saying that superencipherment is always nonsense?
> > > > > Is 2-DES not better than DES?
> > > >
> > > > Given sufficient memory 2-des is not better then des.
> > >
> > > Please exlpain your claim or refer to literature.
> >
> > That is the reason why people use 3DES, and never 2DES.
> >
> > Well this has been explained, for example, in Bruce Schneiers
> > Applied Crypto. At least I think so ;-), I don't have it at
> > hand in the moment. There is an attack which requires masses
> > of memory, but then you can attack 2DES by attacking it from
> > both ends (meet-in-the-middle-attack).
>
> Do you really mean that a 2-DES (with two independent
> keys) is not an jota stronger than DES??
>
> > It is also explained in my other crypto book, "Abendteuer
> > Kryptologie" (Adventure Cryptology), by Reinhard Wobst,
> > Addison Wesley, ISBN 3-8273-1413-5, page 192ff.
>
> It is strange that I found p.192 of this book (1997
> edition) deals with RC5 and not DES or 2-DES. I suppose
> you erred. Could you give the correct page number?
Hmm I have the 2nd edition, it is on page 192 there, in
the chapter "5.2.1 Triple-DES".
WARNING: the following is GERMAN. Translating it would
require too much time and maybe loose details.
"Es gibt eine Methode, doppelte Verschluesselung zu kryptanaylsieren.
Dabei handelt es sich um eine Kombination von Brute Force und einem
Angriff mit bekanntem Klartext. Der Kryptanalytiker stellt sich
sozusagen in die Mitte zwischen beide Verschluesselungen. Auf der
einen Seite chiffriert er den bekannten Klartext mit allen
Schluesseln, auf der anderen dechiffriert er den Geheimtext, und
in der Mitte sollen beide Ergebnisse uebereinstimmen."
[...]
"Im Prinzip reichen schon zwei Klartext-Geheimtext-Blockpaare fuer
diesen Angriff aus. Der Gedanke ist sehr einfach:
Bekannt seien ein Klartextblock P und der zugehoerige Geheimtext
C, entstanden aus der doppelten Verschluesselung:
C = DES(K, DES(K', (P))
Wir chiffriern nun P mit allen moeglichen Schluesseln K' und
speichern die Ergebnisse. Anschliessend dechiffrieren wir C mit
allen moeglichen Schluesseln K und schauen nach, ob das
Dechiffrat unter den erzeugten Chiffraten vorkommt. Wenn ja,
dann testen wir die beiden Schluessel K und K' an einem zweiten
Paar. Bestehen K und K' diesen Test, dann sind es mit ziemlicher
Wahrscheinlichkeit die richtigen Schluessel. Wir koennen nun
weitere, aufwendigere Tests durchfuehren."
[...]
Of course, this attack requires masses of memory, which are
not available today, but this theoretical weakness is enough
that people prefer to use 3DES, instead of 2DES.
------------------------------
From: "Rik Kershaw-Moore" <[EMAIL PROTECTED]>
Subject: Rik Kershaw-Moore/Intl/Herman Miller is out of the office.
Date: Tue, 19 Sep 2000 13:03:00 +0100
I will be out of the office from 18/09/2000 until 04/10/2000.
I am on annual leave until 4th October. If you have any urgent issues
please contact one of the other members of the IS team.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Anders Thulin <[EMAIL PROTECTED]>
Subject: Re: Simple hash function
Date: Tue, 19 Sep 2000 12:36:52 GMT
Runu Knips wrote:
> Hmm but if we have some, say, good 128 bit long checksum (not really
> a cryptographic hash of course) of the record, the chance that the
> record keeps the same checksum after a modification is 1:2**128,
> which is "never" in practice,
In what practice? If simple application testing, it's probably good enough.
But if practice involved starting or stopping a heart-lung system,
or x-ray scanner, a railroad switch, or traffic light system, I'm not sure I
would want to bet on such a hash function.
But I am probably overreacting.
--
Anders Thulin [EMAIL PROTECTED] 040-10 50 63
Telia Prosoft AB, Box 85, S-201 20 Malmö, Sweden
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Optimization for speed question.
Date: Tue, 19 Sep 2000 14:53:42 +0200
"Christian Bau" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <G7vx5.3241$[EMAIL PROTECTED]>, "Tor Rustad"
> <[EMAIL PROTECTED]> wrote:
>
> > The error probability of Miller-Rabin is easy to control, to me proving
> > something on a computer beond a 2^{-80} error probability does not make the
> > proof better.
> >
> > For sake of argument, let us increase the security margin to 2^{-160}.
> > Then if a
> > provable prime algorithm gives a different result than Miller-Rabin did,
which
> > method is right?
> >
> > My bet would be the algorithm which used the less CPU time...
>
> So why did anybody bother proving Fourier's Last Theorem, when it was
> known for some time that a^n + b^n = c^n has no solutions in positive
> integers a, b and c for 2 < n < 125000, so the chances of finding a
> counter example were about 1 in 10^(-300000) ?
You mean Fermat's Last Theorem, this long standing problem for over 350 years?
Perhaps for a Fields Medal, but Andrew Wiles can tell you why (BTW his original
work was flawed).
> Why does anybody try to prove the Goldbach hypothesis, which is known to
> be true with a margin of error < 10^(-1000000) ?
http://www.faber.co.uk/faber/million_dollar.asp?PGE=&ORD=faber&TAG=&CID=
--
Tor
------------------------------
From: "Tor Rustad" <[EMAIL PROTECTED]>
Crossposted-To: comp.lang.c
Subject: Re: Optimization for speed question.
Date: Tue, 19 Sep 2000 15:05:34 +0200
"Dann Corbit" <[EMAIL PROTECTED]> wrote in message
> "Tor Rustad" <[EMAIL PROTECTED]> wrote in message
[...]
> > The error probability of Miller-Rabin is easy to control, to me proving
> > something on a computer beond a 2^{-80} error probability does not make
> > the proof better.
> >
> > For sake of argument, let us increase the security margin to 2^{-160}.
> > Then if a
> > provable prime algorithm gives a different result than Miller-Rabin did,
> > which method is right?
> >
> If it gave a different result, then one of the algorithms is broken.
> Miller-Rabin will either say, "It might be prime." or "It's not prime."
> APR-CL will either say, "It's prime." or "It's not prime."
No, neither algorithm need to be broken.
It has been pointed out elsewhere that Miller-Rabin, is based upon the
assumption that Extended Riemann Hypothesis (ERH) is true.
> For there to be a disagreement, the only possibility is that APR-CL says
> "It's prime." and Miller-Rabin says "It's not prime." In such a case, one
> of the algorithms was coded incorrectly.
Hmmm...if Miller-Rabin state "It might be prime" and APR-CL says "It's not
prime", that qualify for at least for a different return value ;-)
You assume error free HW and aswell ignore the fact that physical prosesses can
affect a computer from doing computations correct. We have to take into
consideration human and physical error-sources, which can affect the computer
from not doing calculations correctly.
When we use a probable algorithm, the error source is built into the algorithm
and the point is to make such an error source insignificant compared to other
error sources. IMHO if ERH is true, there is no need to mandate provable primes
over probable primes.
> > My bet would be the algorithm which used the less CPU time...
> >
>
> Seems irrelevant to me.
It's not, more complex and time consuming calculations have a larger error
probability (when executed on computers in the real world).
Futhermore, more complex algorithms are also more complicated to implement
correctly.
> > > > You did 2 weeks of optimization work, I would instead choosen to drop
> > > > Lucas-Lehmer and Jacobi sum test and settled for probable primes...
> > >
> > > Nonsense. If you want to prove something, Miller-Rabin is simply the
> > > wrong
> > > way to go about it. That is because it *DOES NOT* accomplish the task
> > > at hand.
> >
> > We don't live in a perfect world ;-)
>
> One of us has a complete and fundamental misunderstanding of what a proof of
> primality is.
Ohhh... my understanding of a provable prime is that it is a number which is
*believed* to be prime on the basis of a provable prime algorithm.
> Goldbach's conjecture "might be true."
> To show that there is a 99.99999999999999999999999999999999999% chance it is
> true is no better than 50% chance. You still don't know whether it is true
> or not.
>
> Miller-Rabin does not answer the question. Period.
Neither does a provable algorithm, when implemented by humans and run on a
computer in the real world. Period.
I don't even have to use quantum mechanics to point to the error sources...
--
Tor
------------------------------
From: "H. Ellenberger" <[EMAIL PROTECTED]>
Subject: Re: CDMA tracking (was Re: GSM tracking)
Date: Tue, 19 Sep 2000 14:21:51 +0200
Mack wrote:
> >If you are concerned about your phone being
> >trackable when it is off, why not just put
> >it in an aluminum briefcase ?
> Not terribly effective at attenuating signals.
> It must be properly grounded. The 50 foot of ground
> cable limits the effective range of the phone.
Completely wrong, no ground cable is required.
If the metal briefcase should leak too much rf power,
just put it into a small and tight metallic box.
HE
------------------------------
From: [EMAIL PROTECTED]
Subject: BUG in CryptLib 3.0. Is there a fix?
Date: Tue, 19 Sep 2000 13:14:22 GMT
The following code "hangs up" under Windows NT - Visual Studio 6.0 SP3.
I'm using Peter Gutmann's CryptLib 3.0, downloaded from:
ftp://ftp.franken.de/pub/crypt/cryptlib/beta/cl30beta02.zip
on 30/08/2000.
The program causes an exception randomly. It rarely finishes the 100
times loop without causing the exception.
===================================================================
#define CHECKCODE(st) if (st){ char Txt[100]; sprintf (Txt,"Error %u
Line:%u ", st, __LINE__);\
MessageBox (NULL, Txt,"Error", MB_OK);}
void TestLib(void)
{
int status;
status = cryptInit();
status = cryptAddRandom( NULL, CRYPT_RANDOM_SLOWPOLL );
for (int i=0;i<100;++i)
{
// Create the public key
CRYPT_CONTEXT privKeyContext;
status = cryptCreateContext( &privKeyContext,
CRYPT_ALGO_RSA, CRYPT_MODE_PKC );
CHECKCODE (status);
status = cryptSetAttributeString( privKeyContext,
CRYPT_CTXINFO_LABEL, "Ga", 2);
CHECKCODE (status);
status = cryptGenerateKeyEx (privKeyContext,1024/8);
CHECKCODE (status);
status = cryptDestroyContext (privKeyContext);
CHECKCODE (status);
}
status = cryptEnd();
CHECKCODE (status);
}
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Sylvain Martinez <[EMAIL PROTECTED]>
Subject: Re: Questions about how to run a contest
Date: Tue, 19 Sep 2000 13:27:42 GMT
The new contest is available on:
http://www.bcrypt.com/crypto/contest_uk.html
Good luck !
Sylvain.
---
Unix security administrator
BUGS crypto project: http://www.bcrypt.com
http://www.encryptsolutions.com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Abyssmal_Unit_#3" <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an
alternative intorduction]
Date: Tue, 19 Sep 2000 10:25:09 -0400
this is the basis of most "science", looking at phenomena, formulating hypothesese,
then approximating some human understood "law"
about what has occurred. NO?
so Aristotle created "laws" according to what he understood and perceived at that
time. so what! from then on, (and prior to, no
doubt) many persons unknown have whittled and tweaked the finer points to end up with
what we have at this station in "time".
remember folks!, we ain't the end all of the universe , we don't know all that is to
be known.
we are still mutating ourselves, so try to consider that our future heirs will often
consider that we were a crude bunch of cretins
also!
so, change and transform as you please, it still won't stop the sun from self
extinguishing in a few billion years....
--
best regards,
hapticz
>X(sign here)____________________________________________<
Douglas A. Gwyn wrote in message <[EMAIL PROTECTED]>...
|Kostadin Bajalcaliev wrote:
|> ... here what Aristotle have to say for his own time:
|
|That's funny, because Aristotle's views on physics are not
|held in high regard by physicists.
------------------------------
From: JCA <[EMAIL PROTECTED]>
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption [an
Date: Tue, 19 Sep 2000 07:29:07 -0700
Kostadin Bajalcaliev wrote:
> Douglas A. Gwyn wrote in message <[EMAIL PROTECTED]>...
> >Kostadin Bajalcaliev wrote:
> >> ... here what Aristotle have to say for his own time:
> >
> >That's funny, because Aristotle's views on physics are not
> >held in high regard by physicists.
>
> But, the modern physics would never exist without Aristotle, our hole
> civilization is base on his works.
It is arguable that physics would be far more developed had it not been
for the god-like authority that intervening scholars placed on Aristotle's
views on physics, which were all wrong. This probably hampered adoption
of new ideas for centuries.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: A conjecture - thoughts?
Date: Tue, 19 Sep 2000 14:39:41 GMT
On 18 Sep 2000 22:57:04 GMT, [EMAIL PROTECTED] (Ian Goldberg)
wrote, in part:
>What do you do when f(x) = x * 2 and g(x) = x * sqrt(3) ?
In that case, f(g(x)) = sqrt(3) * g(f(x)), so the two functions do not
commute. Hence, they do not need to be powers of an underlying base
function; they are not involved in the conjecture.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Quasi Algorithms / Quasi Functions and Polymorph Encryption
Date: Tue, 19 Sep 2000 14:42:13 GMT
On Tue, 19 Sep 2000 01:37:42 -0400, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote, in part:
>I tried reading some of the referenced material, but I didn't
>understand some of the arguments, especially the one about
>discarding some bits from an underlying generator to guarantee
>security.
Under some conditions, such as if the underlying generator is
multiplicative congruential or from a shift register, discarding some
of the outputs could, of course, make it harder to predict the output,
if done in some irregular way.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
Date: Tue, 19 Sep 2000 11:01:53 -0400
From: Zulfikar Ramzan <[EMAIL PROTECTED]>
Subject: Re: More Bleh from a Blahish person. ;)
Another way to look at this is as follows. If we view the S-box description as
secret (people do talk about the notion of a key dependent S-box), and we fill the
entries of this nxn S-box in with truly random bits. This S-box, in effect, is a
description of a function sampled at random from the family of all n-bit to n-bit
functions.
Now, we know from Luby and Rackoff that using such functions as round functions in
a 3-round (resp. 4-round) Feistel ladder yeilds a pseudorandom permuation (resp.
super pseudorandom permutation). This means that an adversary will need an
exponential (in n) number of adaptively chosen plaintexts (resp. plaintexts +
ciphertexts) to distinguish the cipher from a random permutation.
This is a theoretical answer since filling an nxn S-box requires picking 2^n
random n-bit strings, which could be prohibitively expensive if n is large. And
in general, "small" descriptions do not always exist (one can always argue this
using Kolmogorov Complexity).
One can also use the Pseudorandom Function construction of Goldreich, Goldwasser,
and Micali, and construct function families with relatively small descriptions,
that appear random to polynomial time bounded adversaries. However, the caveat is
that the concrete parameters necessary to acheive an acceptable level of security
may not always be desirable.
Zully.
Simon Johnson wrote:
>
> Okay, try again... its obvious u've missed the question i'm trying to
> ask (through my bad phrasing.)
>
> What i'm saying is this (not sure if this has been proven/disproven):
> Every mapping of n bits to n bits has a function that will describe it.
> Does this make any sense?
>
> So like: Say we wanted a 8x8 s-box. Instead of using a fixed table, we
> could use an maths function. let F(X) = X + 1 mod 256. We take x and
> compute F(X), F(X) then substitues x. If this doesn't make sense, i
> give up ;)
>
> Okay, now what i was trying to ask was this:
>
> Does a function exist that can describe every s-box? If so, then some
> of these functions must duplicate the *best* s-boxes one can produce.
>
> Say i found such a function in GF(2^32). I could then use this one
> function as my entire f-function, in a Feistel based cipher. Lets say i
> added the round key to the plain-text chunk being encrypted, mod
> (2^32). How many rounds would this require before the best linear and
> differential attack requires more known plain-text blocks than exist?
>
> I believe this is somewhat clearer. If my langauge is incorrect don't
> hesitate to point it out
>
> Thanxs,
> Simon Johnson.
>
> -------------------------
> 'Man is everywhere in chains'
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
--
--Zully
=======
Zulfikar Ramzan (AKA Zully)
Laboratory for Computer Science, MIT
NE43-311, (617) 253-2345
http://theory.lcs.mit.edu/~zulfikar/homepage.html
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: Hamming weight
Date: Tue, 19 Sep 2000 15:08:50 GMT
On 19 Sep 2000 03:38:47 GMT, in
<[EMAIL PROTECTED]>, in sci.crypt
[EMAIL PROTECTED] (Mack) wrote:
>>
>>On Mon, 18 Sep 2000 14:38:36 +0200, in
>><8q51uh$kea$[EMAIL PROTECTED]>, in sci.crypt "kihdip"
>><[EMAIL PROTECTED]> wrote:
>>
>>>Does anybody have an exact definition of 'Hamming weight' ??
>>>(and knowledge of what 'unit' to use - do you say 0,5 ; 50% or something
>>>else ??)
>>
>>See, for example:
>>
>> http://www.io.com/~ritter/GLOSSARY.HTM#HammingDistance
>>
>
>A good definition for base two. But Hamming weight is also
>applicable to other bases. "The Theory of Error-Correcting Codes"
>by MacWilliams and Sloane defines the Hamming Weight as
>the number of non-zero entries in the numeric string and
>the Hamming Distance as the number of places where they
>differ or alternately the hamming weight of subtracting one string
>from the other without carry.
I don't have MacWilliams and Sloane, but both Clark and Cain and
Blahut do say something like "the number of nonzero elements in a
[code] word." Berlekamp is more precise. However, I'm not sure I
have ever seen the distinction used in practice.
Upon opening that door, we would also have to address Lee weight.
If you have a list of things you would like to see improved in the
Glossary, now would be a good time to present it.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
** 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
******************************
