Cryptography-Digest Digest #951, Volume #10 Fri, 21 Jan 00 20:13:01 EST
Contents:
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: Corrections to MYH (David Hopwood)
Re: MIRDEK: more fun with playing cards. ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. ("r.e.s.")
Re: ECC vs RSA - A.J.Menezes responds to Schneier (Greg)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: Ciphers for Parallel Computers ("Joseph Ashwood")
Re: MIRDEK: more fun with playing cards. (CLSV)
Re: RNG for OTPs during WWII (William Rowden)
Re: Intel 810 chipset Random Number Generator (Michael Sierchio)
----------------------------------------------------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 15:25:52 -0800
"r.e.s." <[EMAIL PROTECTED]> wrote ...
: "CLSV" <[EMAIL PROTECTED]> wrote ...
: : "r.e.s." wrote:
[...]
: : > I can easily run off 14-15 letters per minute this way, so
: : > I think this version of "52 card ARC4" is faster than any other
: : > secure card cipher.
: :
: : Please try it out before you make such claims
: : (as Paul Crowley remarked it *is* fun to do).
:
: Please don't be so presumptuous.
: I was speaking from hands-on experience.
Ouch! -- I owe you an apology.
My times were for letters per *3* minutes, not 1,
which means I'm generating ~5 letters per minute.
Still the fastest secure card cipher around?
--
r.e.s.
[EMAIL PROTECTED]
------------------------------
Date: Fri, 21 Jan 2000 23:35:06 +0000
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Corrections to MYH
=====BEGIN PGP SIGNED MESSAGE=====
David Hopwood wrote:
> > Encryption [full version]:
> >
> > 1. Obtain the recipient's authentic public key (m, y, h, l_k), and
> > the current time period t (or a time period in the near future,
> > to take into account delays in delivering a message).
> > Let M be the plaintext message.
>
> Change to:
>
> 1. Obtain the recipient's authentic public key, either in the
> "compressed" form (m, h, l_k), or as (m, y, h, l_k).
> If the former, calculate
>
> y = F[2, m-2](MAKE_y, m, l_k)^(2.s).
^^^
Oops, the sender does not know s. Just ignore the public key
compression for the time being; it doesn't really affect the
analysis.
- --
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
"Attempts to control the use of encryption technology are wrong in principle,
unworkable in practice, and damaging to the long-term economic value of the
information networks." -- UK Labour Party pre-election policy document
=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv
iQEVAwUBOIjs9DkCAxeYt5gVAQFFTAgAxJ1xq9ckjpJ7MDnlviPCTg6K9sx4ks0j
+p58lGFHM3kVWyLcCbZhMP0SAzHX/5Y528YJCn3TqrQXfYmDArpifu9Hf0kAZZH0
XTwidRJ8dMqUm7kuYx1hIpoLc6am/E8TGin+bDSbLTg31KUblFS7EEc1TKdHuWnq
dM7SNmgncbGWAcW5uAm6XPtVU8V7HX2hTtmvi2ZPFu4+x4aWJXJFfvlBGq6HWZej
Nm5Y7qpWefmeKNbI1LSI+CKrN51LRvEP4J/fM/Nd4MRXLAO1wbsYWLpDqEEErQWl
LWWE2cuVAp8jLOoEoqTcG1eCp7E+mHY8HGw5JRg3a1XdFEPjvmeK1A==
=sR76
=====END PGP SIGNATURE=====
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 16:05:17 -0800
I see two major problems with the key setup.
Using the original method of determining the state values for ARC4 leads to
a very large number of keys that have repeated values, not a problem in a
computer but it is a problem for a human with a deck of cards.
Doing the math to figure out the order of the cards using the original
method leads to a great number of potential problems, ie I can create a
password that would be completely impossible to use.
Both of these lead me to believe that if we do chose to base it on ARC4 we
would need to replace the key setup. My initial thoughts on the concept turn
out to be rather a long process, but I believe it yields enough ambiguity to
the initial state to be usable, however I'm still trying to solve for the
allowed entropy with various length passwords/phrases, and even then I'm not
sure if it's useful for a human.
Joe
------------------------------
From: "r.e.s." <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Fri, 21 Jan 2000 16:21:07 -0800
[typo correction]
"r.e.s." <[EMAIL PROTECTED]> wrote ...
[...]
: Here's the routine for the stream generator of "52-card ARC4"
: with 4x13 card-layout, placing the coins adjacent to the cards
: they point to:
: 1) start with the x-coin and y-coin at the upper-left card
: 2) move the x-coin to the next card
: 3) read the card at the x-coin and move the y-coin that
: many cards ahead
: 4) swap the cards at the x- and y-coins
: 5) output the modulo sum of the cards just swapped
^^^^^^^...
Of course that should be be
5) output the value of the card whose location is
the mod52 sum of the cards just swapped
Sorry for the typo.
: 6) return to step 2
:
: Only step 4 involves moving cards -- it takes ~1 sec --
: and moving the coins is now *very* fast because of the mod13
: significance of the rows.
:
: --
: r.e.s. "Mistr Typo"
: [EMAIL PROTECTED]
------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: ECC vs RSA - A.J.Menezes responds to Schneier
Date: Sat, 22 Jan 2000 00:15:46 GMT
> Not in practice. The security of the key generally depends
> only on the size of the key.
So what you are saying is that given a 10kbit key, no matter
how I construct the key (say make up of 500 20 bit primes, it
cannot be broken because the number is just too large for anyone
to figure out? Is that what you are saying? I am not saying this
is wrong. If it is true, I would like to know. That would be
intriguing.
> > and with a quick check because the strength lies in the
> > key itself. With ECC, the strength lies in the curve, not the
> > key,
>
> The security of ECC certainly does depend on the choice of
> private key because if it is small, then it can be found
> by direct search.
But can you not say that about any key search for any cryptosystem?
The strength of ECC is in the key space being too large to
search and too complex to readily determine the factor, which
is a result of the curve and field being used. If you build
an ECC with field size n and you don't want to use key values
less than n/2, then when you go to build the key, make certain
that one of the bits between n/2 and n are set. Just one of them
will solve this problem you point out, particularly if a key space
of n/2 is unsearchable to begin with.
> Further, if it can be guessed that the private key lies in
> a restricted range,...
...then there is something wrong, but what ever it is that is
wrong has nothing to do with ECC or any other cryptosystem.
> With RSA, if the top 20 bits of a key somehow get revealed,
> that info is of no use to NFS. But with ECC if the top 20
> bits get revealed, then you can speed up attacks on the key
> by a factor of 1000.
You are correct, but again this has absolutely nothing to do
with ECC itself. However, if this is such an important issue,
let's talk about it for a moment.
Given an elliptic curve of 500 bits and an RSA key of 500 bits,
if you expose half the bits, which key is likely to be cracked in
our life time?
And if there was a failure somewhere in the cryptosystem that
leaks even one bit, I would be concerned about using that
cryptosystem, not because it uses ECC, but because of the leak.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 22 Jan 2000 00:32:08 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <868fep$67s$[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Michael
]Kagalenko) wrote:
]
]> That's fair comment, however note, that quartz crystals are a very common
]> component of digital equipment, and atomic time standard is available
]> via internet. You can produce thermally random
]> data by measuring the clock drift against more precise clock (first
]> you'd have to find out the crystal frequency, of course). To elaborate
]> a bit, if t is precise time, and t' is the time measured by quartz
]> oscillator (reclaibrated by using t to avoid systematic drift),
]> then
]> <t-t'> = 0 (1)
]>
]>(<> stands for math. expectation), however, that does not
]> mean that there is no drift, but that drift in both directions is equiprobable
]> (the recalibration I mentioned above consists in making sure that (1)
]> holds)
]>
]> If the drift can be assumed to be brownian random walk,
]> the average square drift < (t-t')^2 > grows linearly with time
]>
]> < (t-t')^2 > = constant * t
]
]The nature of crystal oscillators is to have a random variation
]in frequency that varies around the center frequency in a 1/F
]fashion, plus a long term drift in one direction as the crystal
]ages. In addition, you vave to decide when the waveform goes
]from 0 to 1 or from 1 to 0. To do this, you have to measure
]the voltage of a signal with a finite risetime, which means that
]elecrical noise has an effect on how much jitter you see.
All I need to do is measure the clock drift. Aging of the crystal can
be corrected with re-calibartion.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 22 Jan 2000 00:35:03 GMT
Reply-To: [EMAIL PROTECTED]
Paul Koning ([EMAIL PROTECTED]) wrote
]Michael Kagalenko wrote:
]>
]> Paul Koning ([EMAIL PROTECTED]) wrote
]> ]Of course they do. But their signal to noise ratio is high.
]> ]If you're after noise, then you want a source that has a low
]> ](preferably negative) signal to noise ratio. Crystals fail
]> ]that criterion by a very large margin, which is why no competent
]> ]designer uses them for this purpose.
]>
]> That's fair comment, however note, that quartz crystals are a very common
]> component of digital equipment, and atomic time standard is available
]> via internet. You can produce thermally random
]> data by measuring the clock drift against more precise clock (first
]> you'd have to find out the crystal frequency, of course). To elaborate
]> a bit, if t is precise time, and t' is the time measured by quartz
]> oscillator (reclaibrated by using t to avoid systematic drift),
]> then
]> <t-t'> = 0 (1)
]>
]> (<> stands for math. expectation), however, that does not
]> mean that there is no drift, but that drift in both directions is equiprobable
]> (the recalibration I mentioned above consists in making sure that (1)
]> holds)
]>
]> If the drift can be assumed to be brownian random walk,
]> the average square drift < (t-t')^2 > grows linearly with time
]>
]> < (t-t')^2 > = constant * t
]
]I'm not sure what you mean by "thermally random data". It seems
]that you're making a pile of assumptions that may or may not
]be valid.
It seems so to you because you did not understand what I wrote.
]
]The error of a crystal oscillator comes from a number of components.
]First of all there's the manufacturing tolerance of the crystal,
]typically 0.01%. Note that in practice this means the error is
]close to -0.01% or +0.01%, a bimodal distribution. It's a bad
]mistake to think of crystal frequencies as normally distributed!
I said above that the frequency should be calibrated with reference
to reliable clock. What was not clear about this ?
]Then there's drift, caused by temperature variations of the
]crystal, and also by parameter changes in other components of
]the oscillator (which might include things like power supply
]voltage). Since you mention "thermally random" it sounds like
]you're assuming temperature-induced drift is a random function.
No, I assume nothing of a kind. You simply did not I understand the physics
I am trying to use.
]I'd challenge that. In a typical temperature-controlled environment
](e.g., a building) it will have a significant periodic component
]because the temperature control system is a servo system.
]
]There probably is a random component in the frequency variation.
]If you're hard up for a challenge I suppose you could try to
]extract that from underneath all the other components. But for
]goodness sake, WHY? It would be vastly harder, and the bit rate
]vastly slower, than sensible solutions such as a regular noise
]source.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 22 Jan 2000 00:38:57 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Paul Koning) wrote:
]
]>The error of a crystal oscillator comes from a number of components.
]>First of all there's the manufacturing tolerance of the crystal,
]>typically 0.01%. Note that in practice this means the error is
]>close to -0.01% or +0.01%, a bimodal distribution. It's a bad
]>mistake to think of crystal frequencies as normally distributed!
]
]Resistor values, capacitor values, and many other electronics
]parts have an interesting distribution caused by the fact that
]manufacturers make a large number of parts that vary in value
]in a wery wide gaussian fashion, then they sort them by value,
]picking out all of the 0.001% values, then 0.01%, 0.1%, 1%,
]etc. Thus 1% resistors tends to be equally distributed in the
]-1% to -0.1% and +1% to +0.1% ranges.
]
]>Then there's drift, caused by temperature variations of the
]>crystal, and also by parameter changes in other components of
]>the oscillator (which might include things like power supply
]>voltage). Since you mention "thermally random" it sounds like
]>you're assuming temperature-induced drift is a random function.
]>I'd challenge that. In a typical temperature-controlled environment
]>(e.g., a building) it will have a significant periodic component
]>because the temperature control system is a servo system.
]
]We often build a little heater servo to keep the crystal at a
]constant temperature (but even so the temperature control is
]always imperfect - especially when it is optimized for constant
]average temperature instead of constant instantanious temperature!)
]
]>There probably is a random component in the frequency variation.
]>If you're hard up for a challenge I suppose you could try to
]>extract that from underneath all the other components. But for
]>goodness sake, WHY? It would be vastly harder, and the bit rate
]>vastly slower, than sensible solutions such as a regular noise
]>source.
]
]I can see the logic behind trying, but not if you are looking for
]a good RNG. But what if you are looking for a cheap RNG?
]a cheap crystal (or, better yet, ceramic) oscillator costs very
]little, and hooks up to a serial or parallel port easily, and is
]pretty much immune to 60 Hz electrical noise. I agree with
]everything said about the lack of randomness, though. You really
]are just measuring fine differences in the time between reads
]of your serial/parallel port. Such a circuit, if Von Neuman
]compensated and exlusive or'ed with the output of the best PRNG
]you can program, would seem to be, on a practical level, much
]superior to the PRNG alone.
]
No. You are wrong. So long as you can reliably count the number of cycles
of quartz crystal, you can use this to recover thermally random numbers.
Temperature dependence may be indeed a proble, but it can be accounted
for either by thermostabilising or by simply measuring it and feeding
it into computational process.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 00:53:38 +0000
"r.e.s." wrote:
> "CLSV" <[EMAIL PROTECTED]> wrote ...
> : "r.e.s." wrote:
> : > It's simple to use a 4x13 card layout to implement the *exact* ARC4
[..]
> : Please try it out before you make such claims
> : (as Paul Crowley remarked it *is* fun to do).
> Please don't be so presumptuous.
> I was speaking from hands-on experience.
Well my apologies if it sounded that way, it was
more like my amazement sounding through.
> : I think it can be fast given enough practice but
> : 14-15 characters a minute, no way. That is 4
> : seconds for one encryption! On my first try I
> : achieved a speed of about one char in 50 seconds.
> We must be doing something differently.
> Here's the routine for the stream generator of "52-card ARC4"
> with 4x13 card-layout, placing the coins adjacent to the cards
> they point to:
> 1) start with the x-coin and y-coin at the upper-left card
> 2) move the x-coin to the next card
> 3) read the card at the x-coin and move the y-coin that
> many cards ahead
> 4) swap the cards at the x- and y-coins
> 5) output the modulo sum of the cards just swapped
> 6) return to step 2
Ah, you forget a step I believe, shouldn't it be
5) the modulo of the sum of the cards swapped gives
the index to the card whose value is the output
The card swapping is indeed fast but the administration
in my head always slows things down. But that's probably because
I'm not a fast thinker.
Regards,
CLSV
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 00:56:10 +0000
"r.e.s." wrote:
[On ARC4-52]
> My times were for letters per *3* minutes, not 1,
> which means I'm generating ~5 letters per minute.
> Still the fastest secure card cipher around?
Well you're still much faster than I am :-)
Personally I think 2 chars a minute would
be *really* great. But check my remarks in
another post about your procedure.
Regards,
CLSV
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: Ciphers for Parallel Computers
Date: Fri, 21 Jan 2000 16:45:39 -0800
> I'm not qualified to evaluate these claims, based on my current knowledge
> of the NTRU public-key cryptosystem. Can anyone more in the know comment?
I may not be too overly qualified either, but a brute-force attack can
ALWAYS be parellelized, so I believe there's an 8-letter word beginning with
bull that says it all. Of course gettign enough computers to be able to
brute force a properly large public key is impossible.
------------------------------
From: CLSV <[EMAIL PROTECTED]>
Subject: Re: MIRDEK: more fun with playing cards.
Date: Sat, 22 Jan 2000 01:04:52 +0000
Joseph Ashwood wrote:
> I see two major problems with the key setup.
> Using the original method of determining the state values for ARC4 leads to
> a very large number of keys that have repeated values, not a problem in a
> computer but it is a problem for a human with a deck of cards.
I don't think I understand what you mean?
Personally I would communicate a random
permutation of 52 cards as a key and skip
the setup.
Regards,
CLSV
------------------------------
From: [EMAIL PROTECTED] (William Rowden)
Subject: Re: RNG for OTPs during WWII
Date: 22 Jan 2000 01:06:35 GMT
In article <8635if$si2$[EMAIL PROTECTED]>, Paul Rubin
<[EMAIL PROTECTED]> wrote:
> In article <85u8bf$k4s$[EMAIL PROTECTED]>, Bayard Randel
> <[EMAIL PROTECTED]> wrote:
>> Just out of historic interest, would anyone happen to know what
>> sort of RNGs would have typically been used by either Allied or
>> Axis forces for OTP keystream generation ? dice, playing cards ?
Leo Marks, in his memoirs _Between Silk and Cyanide: A Codemaker's War
(1941-1945)_, mentions having FANY's shuffle counters. Later "Letter
One-Time Pads" were machine-made.
There's also the (fictional, but perhaps well-researched?) mention in
_Cryptonomicon_ of secretaries closing their eyes and pulling letters
out of a bin. Later, a response to the question "Why are you here?"
was that someone's secretary became careless and opened her eyes!
--
-William
SPAM filtered; damages claimed for UCE according to RCW19.86
PGP key: http://www.eskimo.com/~rowdenw/pgp/rowdenw.asc until 2000-08-01
Fingerprint: FB4B E2CD 25AF 95E5 ADBB DA28 379D 47DB 599E 0B1A
------------------------------
From: Michael Sierchio <[EMAIL PROTECTED]>
Subject: Re: Intel 810 chipset Random Number Generator
Date: Fri, 21 Jan 2000 17:06:27 -0800
"Trevor Jackson, III" wrote:
> Thank you for the reference. The mood of this paper makes me want to
> ask who paid for the study.
It says quite plainly that it was Intel -- however, Paul Kocher is
a talented and reliable cryptanalyst. Cryptography Research does a
lot of this sort of consulting, I'm sure the fee is the same whether
Intel likes the results of the study or not ;-)
--
QUI ME AMET, CANEM MEUM ETIAM AMET
------------------------------
** 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
******************************
