Cryptography-Digest Digest #417, Volume #11 Sat, 25 Mar 00 06:13:00 EST
Contents:
Re: OFB, CFB, ECB and CBC ("Scott Fluhrer")
Re: ecc equation ("Rick")
Re: Card shuffling (wtshaw)
Re: Fastest DES implementation on Intel PIII ? ("Kasper Pedersen")
Re: http://www.cryptomat.com (Nemo psj)
Re: what is a 2048 bit cipher? (Paul Schlyter)
Re: implementing rot13 (Paul Schlyter)
Re: Download Random Number Generator from Ciphile Software (DMc)
Re: OAP-L3: Answer me these? (Anthony Stephen Szopa)
Re: Re-seeding PRNG's in central key distribution systems (Mark Currie)
Re: http://www.cryptomat.com (Tony L. Svanstrom)
Re: Fastest DES implementation on Intel PIII ? ("Kasper Pedersen")
Re: Card shuffling (Mok-Kong Shen)
----------------------------------------------------------------------------
From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: OFB, CFB, ECB and CBC
Date: Fri, 24 Mar 2000 22:20:13 -0800
<[EMAIL PROTECTED]> wrote in message
news:8bh6gi$oub$[EMAIL PROTECTED]...
> In a previous article, "Scott Fluhrer" <[EMAIL PROTECTED]> writes:
> [--cut--]
> >Actually, you're misunderstanding the problem with ECB that CBC (and CFB)
> >are designed to overcome.
> [--cut--]
>
> This is really off topic, but nevertheless important.
>
> Don't make assertions about what other people understand or don't
understand.
> You don't know that. All you know is what they in fact wrote. Making such
> assertions is more likely to make people upset than to make them
understand.
>
>
> The rest that you wrote is of course true.
You stated that, in response to Mr. Coffin's opinion that the strengths of
the various standard modes were related CBC > CFB > OFB >> ECB:
> You may make CFB and CBC modes sound better than they are. In fact, if you
> know then key and cipher (= E_k) and only two adjactent plain text blocks
> p(n-1) and pn, then you know ahead of time what the cipher block cn will
> be. Hence, the complexity is increased compared to ECB mode, but not that
> much. Using a stronger cipher would probably often be a better way to
increase
> security than to go from ECB mode to either CBC or CFB mode.
Certainly you are mischaracterizing why CBC (and CFB) is generally prefered,
as you yourself seemed to agreed when you stated that what I said was "of
course true". I'm sorry if I assumed that meant you misunderstood the
issue.
(BTW: do you really think that (say) Twofish in ECB mode would "probably
often" be more secure than DES in CBC mode? Certainly not for highly
redundant plaintext, or plaintexts where block-swapping attacks could
apply...)
--
poncho
------------------------------
From: "Rick" <[EMAIL PROTECTED]>
Subject: Re: ecc equation
Date: Sat, 25 Mar 2000 00:12:30 -0600
"Tom St Denis" <[EMAIL PROTECTED]> wrote in message
news:XsNC4.67210$[EMAIL PROTECTED]...
]
] I saw a program called schoof.exe from MIRACL that calcs the order of a
] point on a curve. I tried searching for it, and I found the reference,
but
] I can't find a copy of the description online.
]
] Anyhelp?
]
I believe it is included in the MIRACL download. Go to
http://indigo.ie/~mscott/ to download MIRACL and you should get several good
programs, in addition to the MIRACL library.
Rick
------------------------------
From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Card shuffling
Date: Sat, 25 Mar 2000 01:04:25 -0600
In article <[EMAIL PROTECTED]>, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:
> wtshaw wrote:
>
> Cards are more complicated. Since cards are shuffled by hands,
> the human factor may be quite essential. However, whatever the
> chances of the different permutations, biased or not, there
> is a sense to say that some permutations have higher disorder
> than the others, since the concept of disorder is independent
> of the said chance.
>
It does depend on the game as to how the shuffle will be judged, so it
cannot be the cards alone regardless of the game. surely, the winners
will say that all was fair, a good shuffle was involved, etc; the losers
would likely have a different story.
I've seen times in bridge when no one would bid, so the shuffle seemed
poor to everybody. Depending on how it was played there would have been
winners and losers. So, I still maintain that there is a psychological
element, maybe just a wanting of certainty for a shuffle that tends to
benefit some over others. At times, everyone is happy, but there are
still winners and losers.
> >
> > All shuffles are honest if the person does not know how to manipulate the
> > deck' therefore, all such shuffles of neutral decks are equal. If somone
> > knows a bit too much about how to manage the cards, he can not usually
> > perform an honest shuffle at all.
>
> An honest person may yet shuffle poorly, if he is inexperienced
> in the task or perhaps handicaped due to injury, for example.
>
There are awkward shuffles that are sufficient, and those tending on
perfection that do not seem to be fair, from a biased player point of
view.
BTW, in the posting of the cards, somehow the hammy hand of fate made me
delete a character. Since then, I also wrote the routine that, in
addition from characters to cards, goes from cards back to characters.
These appear to be useful utilities, not only in card games, but in
encryption...don't know if I will quite get the first example of that
finished tomorrow.
--
To see the results of GW Bush's shaddow, visit the Valley;
notice the miserable conditions he allows to fester.
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Fastest DES implementation on Intel PIII ?
Date: Sat, 25 Mar 2000 08:05:47 GMT
"Paul Koning" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Pascal JUNOD wrote:
> >
> > Hi, I'm seeking the fastest DES implementation on the Intel platform.
>
> Don't know if it's the absolute best, but I'd think it's quite
> close at least -- look for Eric Young's libdes, in
>
> ftp://ftp.psy.uq.oz.au/pub/Crypto/DES
>
> paul
We did some hefty optimizing of that some time ago for a keysearcher, but
without chewing up everything.
http://random.subnet.dk/filez/dh007asrc.zip
http://random.subnet.dk/filez/dh007aexe.zip
The DES itself is in a large x86 assembler file. And comes with a sample app
to benchmark it on your platform.
(remeber to cut 6% off the benchmark as it runs 15 rounds most of the time)
/Kasper
------------------------------
From: [EMAIL PROTECTED] (Nemo psj)
Subject: Re: http://www.cryptomat.com
Date: 25 Mar 2000 09:08:50 GMT
Too good to be true.... So I suspect it isnt also.
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: what is a 2048 bit cipher?
Date: 25 Mar 2000 08:06:35 +0100
In article <[EMAIL PROTECTED]>,
Jerry Coffin <[EMAIL PROTECTED]> wrote:
> With that said, there's really no question that your basic idea is
> still correct: 100 bits or so is enough for security for quite a
> while unless there's a major break against the cipher, or a major
> breakthrough in computing technology. Of course it's handy for the
> key size to be a power of 2, so 128-bit keys are fairly common.
> There's honestly little practical purpose for keys a lot larger than
> that -- I realize AES requires support for a 256-bit key, and to
> _some_ extent I can sympathize with NIST requiring: the small key
> used with DES has been a sore point for years, and they're probably
> just (over-)reacting to that criticism. The other point is that it's
> not a _lot_ of extra work to support a larger key, so they might as
> well.
>
> Despite this, it's still basically overkill, and the dramatically
> larger keys some people use are basically pointless as well.
You must distinguish between symmetric and asymmetric ciphers though.
For a good symmetric cipher, a 100-bit key is safe, since virtually
any bit combination is a possible key, and breaking such a cipher
amounts to trying all possible keys, and there are just too many of
them.
Asymmetric ciphers are different: a 100-bit RSA key is almost trivial
to break, since breaking a 100-bit RSA key amounts to factoring the
100-bit modulus (only a very small subset of all possible bit
combinations can be used as keys -- using any others will make those
"keys" even more easy to break). Even a 512-bit RSA key isn't safe
since such a modulus has been factored. To be safe when using RSA,
you must use at least a 768-bit key, preferably a 1024-bit key.
Those who are really paranoid go for 2048-bit keys.
But I've heard of no-one who uses a 2048-bit symmetric key.
Nevertheless the "mimimum size of a safe key" is very dependent on
whether you're considering a symmetric cipher or an asymmetric cipher:
an asymmetric cipher will require a key approximately 10 times larger
to be safe.
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: [EMAIL PROTECTED] (Paul Schlyter)
Subject: Re: implementing rot13
Date: 25 Mar 2000 08:07:47 +0100
In article <[EMAIL PROTECTED]>,
Peter L. Montgomery <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>
> Terje Mathisen <[EMAIL PROTECTED]> writes:
> >[EMAIL PROTECTED] wrote:
>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>
>>> Dan Day wrote:
>>>>>Why not instead:
>>>>>for ( char *s=string; *s; s++)
>>>>> *s += isalpha(*s) ? (toupper(*s)<('A'+13))*26-13 : 0;
>
>>>> Cute.
>>>> Okay, the gauntlet has been thrown -- who can do it in even
>>>> fewer (non-whitespace) characters?
>
>>> replace 'A'+13 with 'N'
>
>>replace 'N' with 78
>
>
> If we assume ASCII representation, we can avoid toupper,
> testing for example
>
> (*s & 31) < 14 ? 13 : -13
> or
> (*s + 2) & 16 ? -13 : 13
> or
> 13 - ((*s + 2) & 16)*5/3
>
> instead of (toupper(*s)>78)*26-13.
> [Experts on C precedence rules may be able to eliminate some parentheses.]
Hmm....
for ( char *s=string; *s; s++)
*s += isalpha(*s) ? 13-((*s+2)&16)*5/3 : 0;
for ( char *s=string; *s; s++)
*s += isalpha(*s)*(13-((*s+2)&16)*5/3);
Now we only need to find a way to replace isalpha() with something
shorter....
--
================================================================
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pausch at saaf dot se or paul.schlyter at ausys dot se
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
------------------------------
From: DMc <[EMAIL PROTECTED]>
Subject: Re: Download Random Number Generator from Ciphile Software
Date: Sat, 25 Mar 2000 09:31:23 GMT
On Mon, 20 Mar 2000 01:31:15 -0800, Anthony Stephen Szopa
<[EMAIL PROTECTED]> wrote:
>From [EMAIL PROTECTED] Mon Mar 20 01:31:15 2000
>Download Random Number Generator from Ciphile Software
>http://www.ciphile.com
>see Downloads Currently Available web page
>OARL3_41.zip (588KB)
>The intended purpose of the OAR-L3: Original Absolutely Random - Level3
>Random Number Generation Software Package is to generate or provide
>random digits or numbers for statistical modeling and computer
>simulations.
>
I downloaded your OARL3_41.zip file, installed it, read the help files
and tutorials, and attempted to generate some numbers. I could not.
Along the way I noted it takes 17 minutes on your 400 speed computer
to run the setup files alone. I also noted I was supposed to fill in
numerous obscurely named fields in I do not know how many input forms.
My tentative thought at this moment is this is a surrealistic prank
program. If not, it is the most user unfriendly program I have seen
since the early days of Apple II's and CPM.
>
>Again, OAR-L3 random number generation software is only intended to
>generate random digits or numbers for statistical modeling and computer
>simulations.
>
As I currently understand from your help files and tutorials, the end
product from this program is random 3-digit numbers from 0 -> 255.
If so, pray tell me how I readily simulate die tosses, or roulette
spins with such a number set? How about probability proportional to
size sample selection? Random walking also seems very constrained by
these very limited random numbers.
Maybe what you mean is statistical modeling and computer simulations
of XOR'ing projects. That seems a severely limited subject matter area
to me.
In conclusion, I am sorry to say I think your OAR-L3 program is too
complexly implemented with too little payoff.
[EMAIL PROTECTED]
------------------------------
From: Anthony Stephen Szopa <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto
Subject: Re: OAP-L3: Answer me these?
Date: Sat, 25 Mar 2000 01:40:48 -0800
Volker Hetzer wrote:
>
> Anthony Stephen Szopa wrote:
>
> > You are sure a great talker. I wonder how many of you are busily
> > studying OAP-L3 theory,
> Everybody who has *access* to that theory. Which is -- nobody.
>
> > It appears that you (and most others) have willfully chosen not to
> > address the theory, and specification of the procedures and
> > processes. This should be noted by all readers to this news group.
> Tell us the theory, then we'll address it.
>
> > It appears that the attack has admittedly been chosen to be an
> > attack on the implementation. No other options?
> Nobody has bothered to "choose" an attack. The goal is to point
> out weaknesses. If you want it for free, provide the source code.
>
> > I thank many of you for unintentionally giving me such credibility
> > (short-lived or not.)
> This is not a chatroom, y'know? People take their time to follow
> threads and look up references (and funny patents). So, forget it.
>
> > By the way, OAP-L3 Version 4.3 will be available in about a week
> > or so. Six new processes are being added to mix things up even
> > more.
> Wow! The more "processes", the more secure. I'm impressed.
>
> Volker
> --
> Hi! I'm a signature virus! Copy me into your signature file to help me spread!
In the lotteries or in Keno (both gambling games) usually there are
eighty ping pong balls numbered 1 - 80. Your goal is to choose 6
numbers. Then these eighty ping pong balls are mixed in a plastic
bubble with blowing air. Six ping pong balls are selected at
random.
Here is your question: if you usually bet one dollar on one game
picking 6 numbers of eighty, if I increased the number of ping pong
balls to 160 (double) and left the amoount you would win the same,
would you now bet two dollars because it doesn't matter how many
ping pong balls are used?
------------------------------
Subject: Re: Re-seeding PRNG's in central key distribution systems
From: [EMAIL PROTECTED] (Mark Currie)
Date: 25 Mar 2000 09:57:45 GMT
Tsk..Tsk.. quite right, I'm sufficiently red-faced, I guess I just got
on-a-roll along a particular line of thought without testing it before posting.
Mark
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>On 24 Mar 2000 10:52:08 GMT, [EMAIL PROTECTED] (Mark Currie) wrote:
>
>>Hi,
>>
>>Consider a system where public and private keys are generated by a central
>>source and distributed to users (often the case in smart card systems). For
>>this example we will assume that RSA(CRT) public and private keys are issued
to
>
>>users (possibly on smart cards). If the private RSA prime factors p & q are
>>found using the output of a prng, it may be possible for a user (knowing his
>>private keys p & q) to predict what other user's private keys are. Since his
p
>>or q (depending on which one was generated last) can reflect the last state
of
>>the prng, he can predict what the next state will be. He can use the same
>>algorithm as the central authority to find the next primes for p & q. He can
>>continue with this for all subsequent user keys until the prng is re-seeded.
>
>Nonsense! An essential requirement of a cryptographically secure PRNG
>is that you CAN NOT the next output of the PRNG, even if you know all
>the previous outputs. The output of the PRNG should not just be the
>state of the thing. The internal state is well hidden by a one-way
>function.
>
>>In general when using a central key distribution system, it should be a rule
>>that if a prng is used then it MUST be re-seeded from a quality random source
>>before each new key set is generated.
>
>In that case, why would they be using a PRNG (P=pseudo)? Why not just
>use a real source of randomness, an RNG, without the P?
>
>doug
------------------------------
From: [EMAIL PROTECTED] (Tony L. Svanstrom)
Subject: Re: http://www.cryptomat.com
Date: Sat, 25 Mar 2000 11:04:36 +0100
Nemo psj <[EMAIL PROTECTED]> wrote:
> Too good to be true.... So I suspect it isnt also.
Then try it and see what happens, as long as they don't have a contract
that they later on can prove that you've read and agreed to and/or you
are not within an area (country) where that contract might be binding
you have nothing to lose.
Anyhow, those cardreaders might have cost them as little as 10 USD (or
even less than that) each, so for what they save in advertising (now
that people tell eachother about this free stuff) they can easily afford
it... and the average cardreader sent out might result in a 10 USD pure
profit (fees, and/or a small part of the money the users spend) along
with maybe 50-100+ USD per user in the system (on the users accounts).
Doing this they might get 10'000 new users within a few months and the
value of that is way beyond what they'd be paying for it.
/Tony... been working on something similar...
--
/\___/\ Who would you like to read your messages today? /\___/\
\_@ @_/ Protect your privacy: <http://www.pgpi.com/> \_@ @_/
--oOO-(_)-OOo---------------------------------------------oOO-(_)-OOo--
DSS: 0x9363F1DB, Fp: 6EA2 618F 6D21 91D3 2D82 78A6 647F F247 9363 F1DB
---���---���-----------------------------------------------���---���---
\O/ \O/ �1999 <http://www.svanstrom.com/?ref=news> \O/ \O/
------------------------------
From: "Kasper Pedersen" <[EMAIL PROTECTED]>
Subject: Re: Fastest DES implementation on Intel PIII ?
Date: Sat, 25 Mar 2000 10:37:59 GMT
If your platform is windoze, that is. oops, the others aren't there.
My screwup. I had to cut it away.
But the source still stands.
/Kasper
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Card shuffling
Date: Sat, 25 Mar 2000 12:02:20 +0100
wtshaw wrote:
>
> BTW, in the posting of the cards, somehow the hammy hand of fate made me
> delete a character. Since then, I also wrote the routine that, in
> addition from characters to cards, goes from cards back to characters.
> These appear to be useful utilities, not only in card games, but in
> encryption...don't know if I will quite get the first example of that
> finished tomorrow.
Just a passing thought: To add some entertainment value of one's
message for the opponent such that he doesn't feel his job to be
too dull and uninteresting, one could with today's techniques
easily emply from time to time codes with diverse nice graphical
symbols, e.g. those of cards or, what I think is quite good looking,
hieroglyphs. (The opponent needs to go outdoors to find the Rosseta
stone and the fresh air and physical activity help to keep his body
fit.)
M. K. Shen
------------------------------
** 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
******************************
