Cryptography-Digest Digest #319, Volume #11 Mon, 13 Mar 00 02:13:01 EST
Contents:
Re: Passphrase Quality ? (jungle)
Re: Cheating in co-operative open-source games, how can we protect from it?
([EMAIL PROTECTED])
Security of cascades (was NIST, AES at RSA conference) (David Hopwood)
Re: Random permutations (Samuel Paik)
Re: Passphrase Quality ? ("Test")
Re: Best language for encryption?? (Jerry Coffin)
Re: Crypto Patents: Us, European and International. (Jerry Coffin)
Re: sci.crypt Cipher Contest (wtshaw)
Re: sci.crypt Cipher Contest (SCOTT19U.ZIP_GUY)
Cipher Contest ("Adam Durana")
Re: NIST, AES at RSA conference (Terry Ritter)
Re: sci.crypt Cipher Contest ("Adam Durana")
Re: why xor?(look out,newbie question! :) ("Douglas A. Gwyn")
Re: Just *Germain* primes ("Douglas A. Gwyn")
Re: How does % operator deal with negative numbers? ("Douglas A. Gwyn")
----------------------------------------------------------------------------
From: jungle <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Mon, 13 Mar 2000 03:11:25 GMT
very good conclusion ...
many people have limitation at they imagination ...
when you are not providing explanation at the AOL user level, majority will not
get it ... and all this has not much in common with the education level ...
Meany Orlik wrote:
> I think of the password grid strategy as a sort of tool. Picture the guy
> who invented the hammer. He didn't have to go around and tell everybody
> what to hit and not hit with it, he just said, "You might find this
> useful." Just as a hammer is good for breaking walnuts but not for breaking
> eggs, my password grid strategy doesn't fit every security situation.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Cheating in co-operative open-source games, how can we protect from it?
Date: 12 Mar 2000 19:13:33 -0800
In article <A9Py4.1453$[EMAIL PROTECTED]>,
Kasper Pedersen <[EMAIL PROTECTED]> wrote:
>When clientA receives status about clientB (what? He had 200 hp before, I
>hit him 500, but he's still 200!?), he can vote that player as cheater. If
>enough clients vote him as cheater, that character gets banned.
Wonderful! Then I'll get together with N of my friends and we'll all hack
our clients - NOT to submit false character data, we'll submit honest
character data, but we'll submit false "cheater" votes against people we
don't like. Then you have to have a vote on cheating in the anti-cheating
protocol, and we can cheat in that vote too, so you need another layer of
voting, and so on.
--
Matthew Skala "Ha!" said God, "I've got Jon Postel!"
[EMAIL PROTECTED] "Yes," said the Devil, "but *I've* got
http://www.islandnet.com/~mskala/ all the sysadmins!"
------------------------------
Date: Mon, 13 Mar 2000 03:14:01 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Security of cascades (was NIST, AES at RSA conference)
=====BEGIN PGP SIGNED MESSAGE=====
"Douglas A. Gwyn" wrote:
> "David A. Wagner" wrote:
> > Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
> > > The assumption was that FH is readily crackable, but FG and G'H
> > > are not. For example, suppose F, G, G', and H each uses 32 bits
> > > of key and that FH can be cracked using radically less work than
> > > a brute-force key search, but FG and G'H cannot. 2^-32 of the
> > > time, the composite system cracks immediately; that is much worse
> > > than either separate system FG or G'H.
> >
> > How on earth can that be?
>
> Because breaking FG or G'H requires ~2^63 "macro" operations in
> every case, whereas breaking FGG'H requires at least that many
> macro operations in almost every case but nearly no operations
> 2^-32 of the time.
These assumptions aren't possible. If FH requires "nearly no
operations" to break, then so does F (proof: encrypt the ciphertext
from F with H and then break it [*]). Therefore, FG will require
"nearly no operations" to break when the key to G is guessed
correctly first time, which also happens 2^-32 of the time.
[*] I'm assuming that "XY" means that X is applied first. For the
opposite convention, FGG'H is provably at least as difficult to
break as G'H (for example), assuming independent keys, in all
attack models.
[argument based on impossible premises snipped]
> An intelligence agency might analyze traffic if it expects that
> one message in 2^32 will be deciphered for some small amount of
> work (after that much work is attempted against a message, it
> would be abandoned), but it might not try to decipher any
> message at all if 2^63 macro operations are required per success.
>
> 2^32 is not such a large number when you consider really
> high-speed communications.
That's why we use keys that are longer than
log2(maximum feasible work factor / maximum desired success probability)
bits. 128-bit keys (for each stage, if we are considering a cascade
with independent keys) easily satisfy this criterion.
- --
David Hopwood <[EMAIL PROTECTED]>
PGP public key: http://www.users.zetnet.co.uk/hopwood/public.asc
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOMxcujkCAxeYt5gVAQFx9Qf/Xz6QBoJYn/OROtADfSLYnLey8rWhIHOv
BB5sJqGkp1thoXoO2yAQ2bOVUdckAoiBsNyPq9VB7UYiyGF0EPVNJWF+8LA3CfJO
G/xn5resKDVVrbWeqKdUXgEVhU1rSRS/n8ISGVZRYG/fphkd8owZuIhFWQ2zKpVX
vB1sAoiwjNMUCSZmb1xVbgsqxTc1+YfVLAJiUpHNj24Cabmi/U99VuBwpcynZX6Z
8AvN3FY84/ISbtkg22uw3fvBFt7tnYljxTvAtRFdc3N9b7V4giv8hMw4fIWKMRd8
7FMl2jAzHFwrgiOnWBuCXT327DdJIkOfWhfvNSPJPW9DLrUuyquIPQ==
=IAy2
=====END PGP SIGNATURE=====
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Random permutations
Date: Mon, 13 Mar 2000 03:56:02 GMT
Mok-Kong Shen wrote:
> The common method of generating a random permutation is that
> due to Durstenfeld (see Knuth), utilising uniformly distributed
> real-valued random numbers in (0, 1] to swap pair of elements.
> Since such random numbers are most often derived from integer-
> valued random numbers through division operations, an alternative
> method suggests itself, basing on the idea underlying the
> well-known procedure in classical cryptography of selecting the
> columns of a polyalphabetic substitution table with the aid of a
> given key. That is, one attaches to the elements to be permuted
> a field which is filled with the integer-valued random numbers
> (one for each element). Subsequently one sorts such records
> according to the said field. I guess that this method of doing
> random permutations (which evidently has nothing new in it) is
> equivalent (in quality) to that of Durstenfeld. Any comments?
Supplying n random numbers to do n swaps is O(n) in time with
a very small constant factor and uses essentially no storage.
Supplying n random numbers than using comparison sorting
is O(n log n). With interpolation sort, you get back to
O(n) but the constant factor is greater than with the usual
algorithm, and you need additional memory.
Divisions may be expensive enough to compensate for the
extra work, but I have doubts.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
You dont know enough about X86 or kernel architectures to argue with me.
- <38b2dc12$0$[EMAIL PROTECTED]> "Leon Trotsky" to Terje Mathisen
------------------------------
From: "Test" <[EMAIL PROTECTED]>
Crossposted-To: alt.security.pgp,comp.security.pgp.discuss
Subject: Re: Passphrase Quality ?
Date: Sun, 12 Mar 2000 21:44:07 -0700
OK, lemme sleep on it.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Best language for encryption??
Date: Sun, 12 Mar 2000 22:14:54 -0700
In article <8abbn3$80a$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
[ ... ]
> > Nope. If you're using a machine where (for example) the null pointer isn't
> > represented by a zero,
>
> Could you name one such environment? Yep, I know it may happen in
> principle, but I've never heard about a real system where it actually
> does happen.
Quite a few IBM mainframes use(d) 0xff000000 as their NULL pointer
value.
OS/2 1.x uses Intel protected mode with a segmented model. Any
pointer with a selector of 0 is a null pointer, even though the
offset may be non-zero.
On Windows NT, any pointer into the first 4 megabytes of the address
space is a null pointer. I don't think it's entirely conforming, but
there's at least one compiler around that assigns different values to
null pointers of different types, so attepting to dereference one
will tell you the type without having to trace back to the code that
did it.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: Jerry Coffin <[EMAIL PROTECTED]>
Subject: Re: Crypto Patents: Us, European and International.
Date: Sun, 12 Mar 2000 22:14:57 -0700
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
[ ... ]
> I am not aware there ever was a specific limit. The inventor is
> supposed to be "moving toward" filing until actually filing. It might
> be reasonable, for example, to spend some time actually testing an
> invention before filing (which thus casts the definition in stone).
> It is normally *not* reasonable to put an invention on the shelf only
> to take it out when somebody else publishes. There have been some
> cases which seem to have had that effect, however, such as the guy who
> invented lasers but did not patent until decades later.
There is language in the law that's intended to cover this: without
trying to quote it exactly, it basically says that if somebody else
has previously invented the same thing, but has abandoned it, their
invention may not prevent you from getting a patent.
There's also some language basically saying they can give preference
to a person who does more in the way of due diligence, particularly
in a case where one person conceives of an idea first, but reduces it
to practice later than somebody else.
--
Later,
Jerry.
The universe is a figment of its own imagination.
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: sci.crypt Cipher Contest
Date: Sun, 12 Mar 2000 22:32:23 -0600
In article <aVRy4.5079$[EMAIL PROTECTED]>, "Adam Durana"
<[EMAIL PROTECTED]> wrote:
> You people don't understand, to have a contest, which requires entries to
> compete against each other, all the entries have to share certain
> similarities. You can't compare a stream cipher to a block cipher, or a
> block cipher with a 64bit block size to a block cipher with a 128bit block
> size. All entries have to be trying to accomplish the samething, and the
> winner is the entry that accomplishes this "thing" in the best way. Someone
> who does not know what a block cipher is, probablly won't enter the contest.
> Plus this is a contest of cipher design, and part of designing a cipher is
> meeting what is required of the cipher. If there were no restrictions
> everyone would submit whatever and it would just be a mess of unrelated
> ciphers.
>
Trying to pick a winner depends on your criteria for winning. I think the
more the merrier if it encorages some to try to write ciphers who have not
tried before. Too bad for those that like everything in order. Neatness
is not the sole measure of value. Trying to discorage the creative spirit
or believing that all must approach things the way you do is nonsense,
although many pretend to have a formula for creativity....be like them.
--
Imagine an internet on an up and up basis, where there are no subversive techniques to
rob a person of their privacy or computer
functionality, no hidden schemes used to defraud anyone. :>)
------------------------------
From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: sci.crypt Cipher Contest
Date: Mon, 13 Mar 2000 06:44:21 GMT
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote:
>Adam Durana wrote:
>>
>> You people don't understand, to have a contest, which requires entries to
>> compete against each other, all the entries have to share certain
>> similarities. You can't compare a stream cipher to a block cipher, or a
>> block cipher with a 64bit block size to a block cipher with a 128bit block
>> size. All entries have to be trying to accomplish the samething, and the
>> winner is the entry that accomplishes this "thing" in the best way. Someone
>> who does not know what a block cipher is, probablly won't enter the contest.
>> Plus this is a contest of cipher design, and part of designing a cipher is
>> meeting what is required of the cipher. If there were no restrictions
>> everyone would submit whatever and it would just be a mess of unrelated
>> ciphers.
>>
>> - Adam
>**********************************
>And what about the components of ciphering machinery?
>
>I would like to submit there something that can be called a
>"Proposed Universal Key Scheduler" based on a 64-byte shift register
>and multiplication (mod 2^32+1). This procedure can accept any key
>lengths up to 512 bit and can produce an arbitrarily long sequence of
>randomized subkey bytes (full avalanche, change of 1 bit in key changes
>all subkeys).
>
>I would like also to submit there a hash function, also based on
>multiplication (mod 2^32+1). Paul Onions poked several holes in an
>early prototype of this function, his ideas about strengthening have
>since been incorporated. The function is scalable, it can produce
>hashes of any size from 64 bit and up in increments of 32 bit
>(so hash sizes of 192 or 224 bits are possible). This function is also
>capable of producing keyed hashes (MACs).
>
Paul Onions found holes in my earler ciphers too. He is not like the
phony crypto gods that get all the press, I wonder what he would think
of this contest.
David A. Scott
--
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website NOT FOR WIMPS
http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page WIMPS allowed
http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
"The road to tyranny, we must never forget, begins with the destruction of the
truth."
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Cipher Contest
Date: Mon, 13 Mar 2000 01:03:10 -0500
I revised the requirements, they can be found at
http://www.wizard.net/~echo/crypto-contest.html This time lets try to stay
on the topic at hand.
- Adam
------------------------------
From: [EMAIL PROTECTED] (Terry Ritter)
Subject: Re: NIST, AES at RSA conference
Date: Mon, 13 Mar 2000 06:18:26 GMT
On Sun, 12 Mar 2000 08:30:38 GMT, in <[EMAIL PROTECTED]>, in
sci.crypt "Douglas A. Gwyn" <[EMAIL PROTECTED]> wrote:
>[...]
>I disagree there. That analysis is for breaking FGG'H in the
>*general* case, which is not my concern. My concern is the
>likelihood of *any* break, not of *every* break. To me, the
>loose term "security of the cryptosystem" has to do with the
>*worst case* (for the legitimate users), not the *typical* case.
>Maybe we should call it "minimum guaranteed level of security",
>assuming we have advanced far enough analytically to make such
>guarantees.
There is something fundamentally wrong with this terminology:
"guaranteed security" does not (and presumably *can* not) exist in
cryptography, since there is always *some* key which solves the
cipher. Clearly, the "level of security" is zero when the opponents
happen to choose the correct key, so the "minimum guaranteed level of
security" can be nothing higher than zero. Furthermore, there *can*
*be* no analytical advances which are advanced beyond this unless they
actually do away with ciphers and keys. The *only* type of security
that exists in cryptography is statistical. There *can* *be* no
"minimum guaranteed level of security."
>[...]
>An intelligence agency might analyze traffic if it expects that
>one message in 2^32 will be deciphered for some small amount of
>work (after that much work is attempted against a message, it
>would be abandoned), but it might not try to decipher any
>message at all if 2^63 macro operations are required per success.
>
>2^32 is not such a large number when you consider really
>high-speed communications.
Right. Don't do that. We do not use ciphers with 32-bit keys, except
to make academic arguments.
The point of multiciphering which has been discussed recently is NOT
to increase the key size, since real ciphers already have (or should
have) large enough keys on their own. The point is to reduce the risk
of exposure from an unexpectedly weak cipher by hiding the weakness
behind other ciphers which each have keys of reasonable size.
---
Terry Ritter [EMAIL PROTECTED] http://www.io.com/~ritter/
Crypto Glossary http://www.io.com/~ritter/GLOSSARY.HTM
------------------------------
From: "Adam Durana" <[EMAIL PROTECTED]>
Subject: Re: sci.crypt Cipher Contest
Date: Mon, 13 Mar 2000 01:24:02 -0500
> Trying to pick a winner depends on your criteria for winning. I think the
> more the merrier if it encorages some to try to write ciphers who have not
> tried before. Too bad for those that like everything in order. Neatness
> is not the sole measure of value. Trying to discorage the creative spirit
> or believing that all must approach things the way you do is nonsense,
> although many pretend to have a formula for creativity....be like them.
Yes I'm trying to make you all conform. I work for the NSA and this is a
new program we started to try to keep new cryptographers following the
current methods we know how to break.
or...
I could be trying to have a contest and not just a mess of ciphers that
could not be compared to each other. If you actually read my post you would
already know this, but you people rather just bitch and whine with out any
suggestions. Really what was the point of this post? You just restated
what was said in 20 other posts, and it isn't even constructive. No one is
going to force you to enter the contest, so if you don't like the format of
the contest and can't think of suggestions to improve it, don't take part.
Its that simple.
But the fact is the 2 basic requirements of entries, that it be a block
cipher and it have a block size of 64bits, leave quite a bit up to the
designer. And the only reason those requirements exist are so entries can
be compared to each other.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: why xor?(look out,newbie question! :)
Date: Mon, 13 Mar 2000 06:44:07 GMT
Mok-Kong Shen wrote:
> Independence of random varaibles is defined in any textbook of
> statistics. You think I need to cite the definition?
You didn't ask about random variables, you asked about bit streams,
then quibbled when I interpreted that as being essentially about
independence of random variables.
So, having rejected the only attempt to help that you received
(at least, via this newsgroup), I suppose you are stuck with no
solution at all. I'm much less inclined to try to help next time.
I won't even mention applying Maurer's universal test to the XOR
of the two streams, or an improvement to that test that recently
appeared in the literature. I don't think you actually *want* a
solution, you just want to argue.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Just *Germain* primes
Date: Mon, 13 Mar 2000 06:59:12 GMT
John Savard wrote:
> In any case, given how overwhelmingly male mathematics still is,
> raising the visibility of female mathematicians isn't all bad.
Germain primes, and Sophie Germain's work in general, is a topic
that came up naturally in connection with the recent attention
focussed on Fermat's Last Theorem. That is fine and proper.
The complaint is in making a special case to call attention to
the fact that she was female in a context where that is irrelevant.
We don't call Gaussian integers "Carl Gaussian integers" in order
to remind everybody that Gauss was male, nor should we. But for
"Sophie Germain primes" evidently a double standard was applied.
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: How does % operator deal with negative numbers?
Date: Mon, 13 Mar 2000 07:05:14 GMT
Stewart Gordon wrote:
> My usual argument for floor-mod is: It's periodic in positive
> numbers, and it's periodic in negative numbers, so why not make
> it periodic across the whole range?
Indeed the standard convention for the mathematical "mod" function
has regular behavior for all signedness combinations of its operands.
But C's (and reportedly, Java's) % operator is not a "mod" operator;
it can be *used* as one for nonnegative operands, but not in general.
------------------------------
** 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
******************************
