Cryptography-Digest Digest #294, Volume #14 Fri, 4 May 01 18:13:01 EDT
Contents:
Re: Message mapping in EC. (Doug Kuhlman)
Re: Best encrypting algoritme (Jim Gillogly)
Re: Random and not random (Mok-Kong Shen)
Re: OAP-L3: "The absurd weakness." (Anthony Stephen Szopa)
Re: OAP-L3: "The absurd weakness." ("Tom St Denis")
WHY I HATE BOSCHLOO (Fight Boschloo)
Re: Encryption Algorythm ("EE")
Re: Best encrypting algoritme (Bill Unruh)
Re: Encryption Algorythm ("Tom St Denis")
Re: Encryption Algorythm ("Scott Fluhrer")
----------------------------------------------------------------------------
From: Doug Kuhlman <[EMAIL PROTECTED]>
Subject: Re: Message mapping in EC.
Date: Fri, 04 May 2001 13:58:03 -0500
Mike Rosing wrote:
>
> Doug Kuhlman wrote:
> > Seems like they were lucky (and/or more is going on than meets the
> > eye). We expect approximately 1/2 of the x values to be on the curve
> > (semi-rigorously, due to Hasse-Weil). With 4 "play" bits, you would get
> > 16 possible x-values. A priori, we would expect to see about 153 (10
> > million / 2^16) "misses".
> >
> > With five bits, you get 32 possible values for x, which means about 1 in
> > 4 trillion values is expected (with no other thought) to "miss" being on
> > the curve.
>
> You lost me. If 4 bits is 1/2^2^4 then 5 bits is 1/2^2^5 is 1 in 4 billion.
> Or am I missing something?
>
My typo. You're supposed to read what I *mean*, not what I say! (yes,
that's tongue-in-cheek). You're right, of course. 2^2^5 is 4 billion,
not 4 trillion.
> > I am, of course, assuming that the position of the "play" bits is fixed,
> > so that there is no ambiguity on the receiver's end. Allowing for more
> > movement of these bits increases the chances of success but seems to
> > needlessly complicate the system.
>
> Yeah, they have to be fixed. Using more play bits is better because you can
> introduce randomness, but that's a different problem.
>
Yep.
> > I am quite sure many mathematicians *have* looked at it. And, yes, it
> > is quite difficult to prove in practice -- at least as difficult as
> > results about densities of primes. There are lots of factors that go
> > into trying to rigorously prove that a point exists in every Hamming
> > sphere of radius n.
>
> Where would I find references? I've been totally guessing at this, am
> not a mathematician, and don't know what keywords to look for. Any mathematicians,
> please chime in!
>
Well, I am a mathematician. I've looked into it. For a while, I
thought it might be my dissertation topic, but it's still too hard a
problem. My advisor looked into it. I know guys like Menezes and
Koblitz have asked that question.
Now, as far as publications, I don't know of any. It's pretty hard to
publish (well, uhh... we looked at this problem. And, well, we got the
obvious heuristic value. But, well, that's about it.) Keywords might
be "elliptic curve" (too many references), points, "Hamming sphere"
wouldn't be bad, but my guess is very few (if any) papers include both
Hamming sphere and elliptic curve.
> > I do accept the empirical *evidence* that it works, though. There is
> > also some sound mathematical reasoning why it should. Proof is a ways
> > away, though.
>
> Hey, it worked for the 4 color map :-) In fact, that's kind of how I started
> looking at it. I plotted rows of "consecutive" x values to see which half
> plane was covered, and seemed to be randomly distributed. After some shifting,
> I saw some patterns, but I couldn't correlate them to anything other than
> my brain saw "patterns". I doubt I could follow the math, but I'd still be
> interested in any published papers.
>
Yeah, but the 4-color problem has a lot of limiting structure that
discussions of Hamming spheres in elliptic curves don't. For one thing,
the size of the base field is allowed to be arbitrarily large, which
leads to an asymptotic estimate, which is always harder to do. The
rules of mappings are also very well-established, whereas point density
locations in ECs aren't (to my knowledge, anyway).
A more fundamental problem is that a "Hamming sphere" is not a very nice
abstract algebraic object. It doesn't obey rules like we want it, too.
This makes proof extremely difficult.
Since the proof appears to be very difficult and the heuristic appears
to work pretty well, it's hard to justify why anyone should get into the
problem right now.
If you do succeed in finding anything on this topic, though, please let
me know, as I would be quite interested.
Doug
------------------------------
From: Jim Gillogly <[EMAIL PROTECTED]>
Subject: Re: Best encrypting algoritme
Date: Fri, 04 May 2001 12:13:14 -0700
david wrote:
> Im making a backup program, and I don'treally know what is the most secure
> algoritme, im using Rijndael rigth now and using 256 bit keys, are rc6
> stronger or are there others??
The strength of Rijndael will not be the weakest part of your
backup system. You don't need to shop for a more secure algorithm.
--
Jim Gillogly
Sterday, 13 Thrimidge S.R. 2001, 19:12
12.19.8.3.9, 4 Muluc 7 Uo, Sixth Lord of Night
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Random and not random
Date: Fri, 04 May 2001 21:13:27 +0200
Matthew Skala wrote:
>
> Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
> >some reason for me convenient), (2) I don't look at the
> >pad but arbitrary change the order of the messages to K2,
> >(3) I look at the pad and based on the information changed
> >it to an order K3 which 'by chance' happens to be identical
> >to K2. Why is (2) secure and (3) not secure? See also
>
> Scenario (3) does not have the perfect secrecy property, while scenario
> (2) does, because in scenario (2) the plaintext and key are independent
> and in scenario (3) they are not independent. Independence of plaintext
> and key is a requirement for perfect secrecy. That requirement is met in
> scenario (2) and not met in scenario (3).
>
> I am boycotting CRC Press because of their legal harassment of Dr. Eric
> Weisstein, which you can read about at http://mathworld.wolfram.com/ .
> My open letter to them is at http://www.islandnet.com/~mskala/crcpress.txt .
> I am therefore loath to recommend a book they publish. However, I have a
> copy of Stinson's _Cryptography: Theory and Practice_ which I was given to
> use while TA'ing a course where it was the text, and it's a standard
> reference on these kinds of topics which you might want to look at in a
> library. Independence of random variables is in Definition 2.1 on page
> 45; perfect secrecy is Definition 2.2 on page 48. Perfect secrecy is
> defined as independence of plaintext and ciphertext; from that it is
> trivial to derive that independence of plaintext and key is a requirement.
> This is not something that's open to debate; it's a theorem. Using some
> approximation of Stinson's notation:
>
> For all plaintext x in P, ciphertext y in C, let the key z = x XOR y
> which is in K, then:
>
> p_p(x|y) = p_p(x) (perfect secrecy by definition 2.2)
> if and only if x and y independent (corrollary 2.2)
> if and only if p_c(y|x) = p_c(y) (corrollary 2.2)
> if and only if p_k(z|x) = p_k(z) (definition of z above)
> if and only if z and x are independent (corrollary 2.2)
> Q.E.D.
>
> Corrollary 2.2, for reference, merely states that independence of a and b
> is equivalent to p(a|b) = p(b), which is more convenient than the literal
> definition of "independence means p(a and b) = p(a)*p(b)".
You have given a LOT of theory but in my view failed to
'straightforwardly' answer my previous 'plainly formulated'
question, namely HOW (2) and (3) CAN have ANY difference
to the opponent. He gets (because of the 'chance' event I
assumed) in the two cases EXACTLY the SAME set of encrypted
messages (exactly the SAME bit sequences). HOW can he crack
in the one case, while not in the other?? Does he perhaps
have ability of 'clairvoyance' to know that in one case I
have looked at the pad while in the other case I didn't??
To repeat, if you were the opponent, HOW do YOU know
whether you are in situation (2) or in situation (3)? Could
you please clearly say something to this point, i.e. your
techniques of distinguishing (2) from (3) using the specific
materials (the encrypted messages, the bit sequences) that
you concretely have in your hand?
>
> >I don't yet understand your 'independence' argument. The
> >different segments (in fact the different bits) of OTP
> >are 'independent' from one another by definition of the
> >property of OTP (in contrast, segments of output of a
> >PRNG are not entirely independent, there being correlations).
> >So suppose the segments are S1, S2, S3 (happen to be
> >generated by the source in this order). The corresponding
> >messages can be M1, M2, M3 or any of the possible six
> >permutations of these. Isn't it that EACH and EVERY of
> >the permutations is secure by the theory of OTP 'from
> >the very beginning'? If no, why? Suppose the answer is yes.
>
> Let's play poker. I will deal out two poker hands fairly from a
> theoretically perfect unbiased shuffled deck, and I will somehow choose
> one hand to give to you, and keep one for myself, without looking at them.
> Then we each reveal our hands and whoever has the highest-ranking hand
> wins. We'll assume that we assign values to suits so as to put a total
> ordering on possible poker hands - there's no possibility for the two
> hands to be ranked equally. This game is fair, right?
>
> Now, let's play again. I will deal out two hands fairly, just like
> before, and then I'll look at them, and choose one to give to you and keep
> the other for myself based on what I see. Then we each reveal our hands
> and whoever has the highest-ranking hand wins. Do you want to play this
> game? Why or why not?
>
> If you were an observer watching me play these two games with someone
> else, and you have to, in each case, make a side bet on who will win the
> game, assuming I want to win, which game would you prefer to bet on? In
> which game is it easier to guess who will win?
>
> The two poker hands in the second game were generated by exactly the same
> procedure that you agreed was fair in the first game, and it might occur
> that I might make exactly the same choice of which hand to give you, that
> I would have made without looking anyway. So by what I think is the same
> logic you're trying to apply to the OTPs, the second game should be
> perfectly fair, and in both games I should have exactly 0.5 probability of
> winning. But if you or anyone else would like to play the second game
> with me, I'd be very happy to let you. I'll even give you ten to one
> odds. I'm sure we can find a mutually trusted third party here in
> sci.crypt to hold the money and generate a randomly-selected permutation
> of the 52-card poker deck.
>
> Looking at random selections, and changing your use of them based on what
> you see, makes them not random.
I beg you pardon to say that I have the impression that
you have entirely ignored to 'directly' answer my question
in the above quote of mine. Could you please, at least
for this moment, first refer to the quote of my previous
follow-up above and answer in a concise and direct manner
to the one question there, namely:
Isn't it that EACH and EVERY of the permutations is
secure by the theory of OTP 'from the very beginning'?
If you like, you could currently 'explicitly' add the
assumption that I don't look at the pad, i.e. I use the
OTP 'entirely' 'normally'. (The other case where I look at
the pad could be debated later.) To repeat: I have three
segments S1, S2 and S3 obtained from the OTP source, and
I have in my hand three messages denoted (named) M1,
M2 and M3 (these are NOT a priori ordered in any sense,
i.e. the suffixes 1, 2 and 3 do not give any ordering),
MUST I process M1 with S1, M2 with S2 and M3 with S3
OR am I on the other hand entirely FREE to CHOOSE (say,
just according to what I momentarily find convenient with
my hand to handle these messages) which messages to be
processed by which OTP segments, i.e. an arbitrary
permutation (determined without my consciously thinking
about it) of the orders of the given messages relative
to the OTP segments (if we consider the OTP segments to
be in the order S1, S2, S3)? Only after you give a clear
and definitive answer (including a global Yes/No) to this
short yet very essential and critical question could we
profitably proceed to further points of our debate in my
humble view.
Thanks in advance.
M. K. Shen
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Fri, 04 May 2001 12:32:02 -0700
Tom St Denis wrote:
>
> "Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > OAP-L3: "The absurd weakness."
> >
> > The process of random digit generation used in OAP-L3 can be reduced
> > to this simplicity:
>
> <snip>
>
> Just cause your cipher can use big numbers does not make it secure.
>
> For example, Lucifer had a 128-bit key space but the best attack doesn't
> require 2^128 work.
>
> You have to prove that your cipher is statistically unbiassed using as many
> tests as possible. And you also have to show that the information leakage
> is minimal (if you think it's zero you really should go sell lawn umbrella's
> instead).
>
> Tom
With your many previous vague and less than precise posts you must
explain exactly what YOU mean by "leakage."
Not what "leakage" has been defined by others but in your own words
what you understand this word / concept to mean.
There can be no discussion on what YOU mean by "leakage" unless
you define it in your own terms because you frequently are ambiguous
and we cannot assume that you even know what you mean.
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.hacker,talk.politics.crypto
Subject: Re: OAP-L3: "The absurd weakness."
Date: Fri, 04 May 2001 20:34:57 GMT
"Anthony Stephen Szopa" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> With your many previous vague and less than precise posts you must
> explain exactly what YOU mean by "leakage."
>
> Not what "leakage" has been defined by others but in your own words
> what you understand this word / concept to mean.
>
> There can be no discussion on what YOU mean by "leakage" unless
> you define it in your own terms because you frequently are ambiguous
> and we cannot assume that you even know what you mean.
Leakage means what it implies. Every output byte must leak some (perhaps
little) info about the input state, this is always going to happen.
The real question is how much info is leaked, i.e how many bytes (bits,
etc...) are required to learn enough about the internal state.
Tom
------------------------------
Date: 4 May 2001 21:09:32 -0000
From: [EMAIL PROTECTED] (Fight Boschloo)
Subject: WHY I HATE BOSCHLOO
Crossposted-To: alt.privacy.anon-server,alt.security-pgp
I hate Boschloo
===============================================
HISTORY:
That Boschloo bozo is a clown and a troll who has been looming around for nearly a
year.
Don't mistake a "regular" (troll) with a knowledgeable person: that self-proclaimed
"security expert" is not even a remailer user. In the past, he proved himself unable
to check a PGP signature, and got ridicule from every single technical topic he wanted
to talk about.
Besides false or inaccurate or misleading technical misinformation, his posts are
about his avowed mental illness, or for bashing remops or real freedom fighters: he
likes to quarrel with every one, and stir shit. Sometimes, it is even pure delirium
(when he misses his pills?)
One of his last actions was to stage a hoax about his own suicide, just to try to grab
some sympathy, after he had been exposed as a troll and technically incompetent.
The worst being his teasing of Script-Kiddie until it triggered a new flood on apas.
Of course, he refuses to apologize.
Actually, the level of contempt he shows for remailer users:
they don't give their names, while he does
that can't do anything against him, without giving their names
is in no way different from what is displayed by Pangborn, Burnore and the like
Ignore him completely, killfile him, respect others' killfiles
KILLFILE:
To put him in your killfile, put "Author: Boschloo"
That will make disappear both him and people who warn about him
If you want to tell him to buzz off, or warn about him,
use a nickname containing "Boschloo" (Boschloo Hater, Boschloo Sucks,...)
to accomodate such killfile for "regulars", and still warn newbies
COURAGE:
Boschloo is getting _no_ answer from apas any more.
He has to crosspost to various newsgroups to try to grab some attention.
In a few months, it will be gone.
------------------------------
From: "EE" <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorythm
Date: Fri, 4 May 2001 15:21:59 -0400
Well, the algorithm is a modified version of RC4. I would want to know how
secure it is against any kind of attack. Please let me know if you need more
information.
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:g1oI6.10541$[EMAIL PROTECTED]...
>
> "EE" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > Is there a way to know if an encryption algorithm is secure? I would
also
> > like to know how strong this algorithm is.
>
> Yes.
>
> What algorithm against what attacks? Your question is not complete
>
> Tom
>
>
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: Best encrypting algoritme
Date: 4 May 2001 21:39:10 GMT
In <e2DI6.7260$[EMAIL PROTECTED]> "david" <[EMAIL PROTECTED]>
writes:
>Hi all.
>Im making a backup program, and I don'treally know what is the most secure
>algoritme, im using Rijndael rigth now and using 256 bit keys, are rc6
>stronger or are there others??
I want to put a bumper on my 1950 VW. At present I have put on a 1 foot thick
Ibeam, but am wondering whether a 24 inchdiameter log might not be better. What
is the best bumper for my VW?
Your question is silly. There are so many other holes in your system
that your question is irrelevant. Something like 56 bit
DES would probably already be overkill. (And yes I say this having
never seen your system).
------------------------------
From: "Tom St Denis" <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorythm
Date: Fri, 04 May 2001 21:42:41 GMT
"EE" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Well, the algorithm is a modified version of RC4. I would want to know how
> secure it is against any kind of attack. Please let me know if you need
more
> information.
Well I can't tell off hand, you haven't sent the algorithm yet.
Tom
------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: Encryption Algorythm
Date: Fri, 4 May 2001 14:37:20 -0700
EE <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Well, the algorithm is a modified version of RC4. I would want to know how
> secure it is against any kind of attack. Please let me know if you need
more
> information.
Well:
- What do you mean by "secure"? What's the "threat model"? In particular,
what attacks do you care about? Do you care about unauthorized people
reading the messages, undetectably altering valid ones, or forging new ones?
What resources does the attacker have? Is the attacker your kid sister, a
bored hacker, a large corporation, or a major world government?
- What do you mean "a modified version of RC4"? Well, how secure it would
be might also depend somewhat on exactly how you modified it. In
particular, why don't you use a peer-reviewed cipher (such as unaltered RC4,
AES, 3DES if what you care about is privacy)
>
> "Tom St Denis" <[EMAIL PROTECTED]> wrote in message
> news:g1oI6.10541$[EMAIL PROTECTED]...
> >
> > "EE" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]...
> > > Is there a way to know if an encryption algorithm is secure? I would
> also
> > > like to know how strong this algorithm is.
> >
> > Yes.
> >
> > What algorithm against what attacks? Your question is not complete
> >
> > Tom
> >
> >
>
>
------------------------------
** 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
******************************
