Cryptography-Digest Digest #356, Volume #10       Sun, 3 Oct 99 15:13:03 EDT

Contents:
  Re: radioactive random number generator (Rolf Bombach)
  Help Doing a DPA. Can sombody do that. Need software? (Goran)
  Re: Are small block sizes less secure? (SCOTT19U.ZIP_GUY)
  Re: Factoring public keys attack? (Kent Briggs)
  Re: SNAKE Web Page (Paul Onions)
  Re: Announcement of results (Alex)
  Re: RSA-512: Weizmann Institute: London Times (ca314159)
  Re: Perfect Shuffle Algorithm? (Scott Nelson)
  Re: Factoring public keys attack? (DJohn37050)
  Is 128 bits safe in the (far) future? ("Thomas J. Boschloo")
  Re: radioactive random number generator (Larry Phillips)
  Re: radioactive random number generator (Jeff Brandenburg)
  Re: Addition/subtraction mod 256 vs. XOR (fungus)

----------------------------------------------------------------------------

From: Rolf Bombach <[EMAIL PROTECTED]>
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Subject: Re: radioactive random number generator
Date: Sun, 03 Oct 1999 14:16:04 +0200
Reply-To: [EMAIL PROTECTED]

Dave VanHorn wrote:

> Ross <[EMAIL PROTECTED]> wrote in message
> [...]

> This is an idea I put forth in circuit Cellar discussions years ago.
> Everyone freaked out over using radioactives, even though it's only alpha
> particles that can be stopped by paper.

If you can make sure the source stays in the chip then the alpha emitter
is harmless. If there is a chance the stuff gets into your body, alpha
emitters are one of the most harmful radioactive materials (rule of
thumb: factor 10 more than gamma). Solution: not exceeding allowed
amount of Bq's. Anyway, today's regulations concerning radioactive
material are ..hm.. (sorry, non english speaking, i miss the word..).

> The distribution won't change. The total amount may change, but the time
> between hits will still be random.

Yes and no. The time between hits has a distribution. The most probable
time between hits is zero, then the curve goes slowly down, some
exp(-ax). It's contrary to some "intuition", it's a great problem/nuisance
for geiger counters.Even a short "dead-time" may have a big influence on
readings. If you have the opportunity, do the experiment. Connect output
of geiger counter to interrupt line, small routine doing the pdf (probability

density function, not that internet stuff :-) ). I checked it, it works.
If your random number generator does not account for that, the
"randomness" is spoiled. (And there are other statistical effects, too...)
IMHO a great idea, but as with many great ideas, much more work than
planned to get them working properly.

--
Rolf Bombach      [EMAIL PROTECTED]




------------------------------

From: me@home. (Goran)
Subject: Help Doing a DPA. Can sombody do that. Need software?
Reply-To: aa
Date: Sun, 03 Oct 1999 12:48:18 GMT

Hi there

I wanna do a DPA on a card I have.
I have plain/and chipher that are correct and wanna take the m-keys
out of the card.
It uses trippel des with to keys.

Need software that can help me with this work.

Best Regards

Goran

[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Are small block sizes less secure?
Date: Sun, 03 Oct 1999 14:14:36 GMT

In article <7t6h7r$koe$[EMAIL PROTECTED]>, Tom St Denis <[EMAIL PROTECTED]> wrote:
>In article <7t4ubn$ifc$[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
>> In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Johnny
> Bravo) wrote:
>> >On Sat, 02 Oct 1999 01:52:17 GMT, [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
>> >wrote:
>> >
>> >>  You clipped the text but that is ok. If you want proof which I doubt you
>> >>do. You and your asshole friends can make up a contest that is like
>> >>my scott19u contest and I will solve it for you. But do you have the brains
>> >>to make such a contest.
>> >> I doubt it. Your are talk and no action.
>> >>
>> >>David A. Scott
>> >
>> >  In other words you have no such proof, your entire argument consists of
>> >unsubstantiated statements and insults.  No wonder people don't take you
>> >seriously.  You made the claim, back it up if you can.
>> >
>> >  Johnny Bravo
>> >
>>
>>   No in other words I can prove mine stronger by example at least in this
>> areaa but obviously your todumb to understand or even create an example.
>
>You know what the funny part is? The block size in Scottu19 is the smallest I
>have seen yet.  Even DES has a larger block size...
   Thats because you don't know what a block size really means. The
operations in scott19u are 19bit. but if you look at scott4u they are 
4 bit operations.  Just like IDEA which only uses 16 bit operations
it still gets classidef by the big boys as 64 bits.
  We have gone down this road several times. You seem incapable of
learning. Scott19u is actaully a varible block cipher the length of the
block is the length of the file. Ask your buddies Mr BS and Wagner
I think you claimed they like you and even anwser your mail. Which
is more than what they would do for me. Tell what Wagners anwser
is. Is Scott19u a 19bit block cipher or a whole file cipher. I am sure
he has looked at it enough to anwser this question for you. 
  But as usually your just shooting your mouth off with out any
real thought of what you say.

>
>Tom
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.


David A. Scott
--
                    SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
                    http://www.jim.com/jamesd/Kong/scott19u.zip
                    http://members.xoom.com/ecil/index.htm
                    NOTE EMAIL address is for SPAMERS

------------------------------

From: Kent Briggs <[EMAIL PROTECTED]>
Subject: Re: Factoring public keys attack?
Date: Sun, 03 Oct 1999 15:02:00 GMT

UBCHI2 wrote:

> Instead of trying to factor a prime based public key after somebody has used
> it, why not have a lookup table of all the keys.  It is quicker to create the
> keys than to factor a key.  So just do the following:

According to Schneier, there are approximately 10^151 primes 512 bits in length or
less but only 10^77 atoms in the universe.  Where do you suggest we store this
lookup table?

--
Kent Briggs, [EMAIL PROTECTED]
Briggs Softworks, http://www.briggsoft.com



------------------------------

From: Paul Onions <[EMAIL PROTECTED]>
Subject: Re: SNAKE Web Page
Date: Sun, 03 Oct 1999 15:26:18 +0000

Peter Gunn wrote:
> 
> [EMAIL PROTECTED] wrote:
> 
> > In the context of SNAKE this means that g should be chosen so as not to
> > be congruent to 1 or -1 for all primes in the array.
> 
> ok, no negative numbers in SNAKE, so

Not quite right.  The issue is whether g is *congruent* to -1 for any of
the primes in the array.
 
> SQRT(max modulous) < g < max modulous
> 
> should always be ok (max modulous always huge of course :-)

Careful with that upper bound.

If the primes are all very close in value then it may be possible to create
a g greater then some primes in the array (but less than the maximum one)
such that g mod Qi is again a small number for those primes s.t. g > Qi.

This gives the attack a chance of success once again.

I'd restrict g such that:-

  SQRT(max[Qi]) < g < min[Qi]

>
  [...]
>
> > Seriously though, one idea might be to use a "random" g of some kind.
> > But this is straight from the top of my head, and so I don't know how
> > this might be done or what weaknesses it may introduce.
> 
> Right, how about using a value for g based on R??
> 
> say g = SQRT(max modulous) + (R mod SQRT(max modulous))
> 

Well, not exactly as you stated because SQRT(max modulous) is not an integer.

But it certainly seems plausible to base g on R.  Keep in mind though that
you are now allowing A to choose the generator, and so any attacks by an
adversary that impersonates A have that extra degree of freedom to play
around with.

> I guess I just have to try and defeat any attacks as they are discovered
> since there is no way to prove that all possible attacks have been defeated.
> 
> So, Im thinking that I will adjust the SNAKE web page to just state
> that g must be in range....  SQRT(max modulous) < g < max modulous
> until Ive had a chance to think about the implications of allowing a value
> for g based on R. I will also specifically state that Vi, Wi != g must be
> checked.

Yes, seems sensible (subject to my comment on the upper bound of g).

Regards,
Paul(o)

-- 
Paul Onions                     [EMAIL PROTECTED]
                                 PGP 2.6.3 key available
                            D704688BEFBF2D5D 546BC1D603E2A8E0

------------------------------

From: Alex <[EMAIL PROTECTED]>
Crossposted-To: comp.theory
Subject: Re: Announcement of results
Date: 03 Oct 1999 12:06:23 -0400


Hi.  I am unable to reconstruct the documents file:

% unzip diagramsps.ZIP 
Archive:  diagramsps.ZIP
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of diagramsps.ZIP or
        diagramsps.ZIP.zip, and cannot find diagramsps.ZIP.ZIP, period.

What am I doing wrong?

Alex.

------------------------------

From: ca314159 <[EMAIL PROTECTED]>
Subject: Re: RSA-512: Weizmann Institute: London Times
Date: Sun, 03 Oct 1999 15:28:05 GMT

Douglas A. Gwyn wrote:
> What I want is more info on the supposed Weizmann device
> that cracks a 512-bit RSA key in 12us.

 "The institute was founded a few weeks after
 news leaked from the Israel's Weizmann
 Institute that it was using a mixture of
 quantum computing and special optical
 technology to break the RSA-512 code, the
 system used by the European banking system.
 It claims it has developed a hand-held
 device that can break the code in 12
 microseconds."

  Twinkle could be called "special optical technology"
   http://www.rsa.com/rsalabs/html/twinkle.html

  and anybody could say that if a photon was involved
  in any way, that it was "quantum computing", or cryptanalysis,
  but the transfer of information from point A to point B
  without any physically measureable intermediary would
  more likely be called "quantum cryptography" or maybe
  "psychic communication".

   http://www.newscientist.com/ns/19991002/quantumcon.html
  
  

-- 

http://www.bestweb.net/~ca314159/
Croton-Harmon

------------------------------

From: [EMAIL PROTECTED] (Scott Nelson)
Crossposted-To: sci.stat.math,sci.math
Subject: Re: Perfect Shuffle Algorithm?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 28 Sep 1999 06:59:34 GMT

On Tue, 28 Sep 1999 00:50:40 GMT, [EMAIL PROTECTED] wrote:

>I was given a problem for a job interview for a computer programming
>job.  I was to write a routine that cuts a computer simulated deck and
>performs a perfect shuffle.  A perfect shuffle, you cut the deck x cards
>from the top.  Then the bottom card from the top stack deck goes down
>first, then the bottom card from the bottom of the deck on top of it,
>one at a time, until one of the stacks runs out, then the remaining
>cards go on top of the deck.  I was to simulate this pretty easy in JAVA
>and it works fine.  The question he had was if the deck was 1001 cards,
>and you cut from the top 102 cards, then perfect shuffled, how many
>times would you have to shuffle the deck to return it's to it's original
>order?  My algorithm works, but runs slow for large decks.  I let it run
>for 16 hours, it shuffled 800,000,000+ times and I suspended it.  He
>says there is a much simpler, faster way to come up with the answer,
>than the way I did it.
>
>They way I did it, is I created an array of 1002 cards (ints)  in
>computer memory, set the card value to it's original array index, then
>created a 2nd array, shuffled the 1st into the 2nd, compared to see if
>the 2nd array was in the original order, if not, copied the 2nd array
>back into the deck, and repeated until the came up in th4e right order.
>
>Does anybody have any ideas, how to do this simpler, faster?
>

I'd determine all the cycles in the deck and find their least 
common multiple.  This may have some errors, since it's just 
off the top of my head, but I think you can get the idea:

Clear an array.
set lcm = 1
while there are still unmarked cards, {
  order the deck.
  Pick a card in a currently unmarked location.
  while the chosen card is still in an unmarked location, {
      mark the current location in the array.
      shuffle the deck once
  }
  set lcm = the least common multiple of the number of steps in 
             loop2 and the current value of lcm.
}

This shouldn't take more than 1002 steps to complete.  
Although finding the LCM isn't exactly easy, for numbers 
smaller than 1000 you can just brute force it.  
If speed was really important, you could keep track of all 
the prime factors of lcm, but there aren't all that many 
cycles.

Scott Nelson <[EMAIL PROTECTED]>


------------------------------

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Factoring public keys attack?
Date: 03 Oct 1999 16:59:50 GMT

Gosh, are there lots of primes?
Don Johnson

------------------------------

From: "Thomas J. Boschloo" <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Is 128 bits safe in the (far) future?
Date: Sun, 03 Oct 1999 20:05:23 +0200

Arne Hoffmann wrote:
> 
> ... but in a paper of Ralf Senderek I read this:
> 
> ______________________________________________________________________
> 

<snip>

> If you assume the size of a high-performance computer system performing
> keytests is 0.3 mm for electronic or optical transfer of information, it
> can only perform 1 000 000 000 000 operations (10^12) per second,
> otherwise it has to be smaller. Over a period of 317 years or 10 003 759
> 200 seconds that will sum up to 10 003 759 200 000 000 000 000
> operations. This ability to perform no more than 10^22 operation during
> 317 years is truly not sufficient for testing 10^22 different IDEA-keys
> because every keytest requires more than a single operation cycle. But
> even if it was possible to do a keytest that fast, the large number of
> 10^38 IDEA-keys would be searched for no more than 0.000 000 000 000 000
> 029 percent. Thus a specific IDEA-key will not be found even if "lots"
> of those high-performance computers will work parallel to test the keys.

But if the size of one functioning component is 1 Angstrom unit (1e-10
m), and the size of the computer system is 0.3 x 0.3 x 0.3 mm^3, the
numbers would become different.

(3e8 m/s) / (1e-10 m) = 3e18 operations a second
(0.3 mm)^3 / (1e-10 m)^3 = 2,7e-11 m^3 / 1e-30 m^3 = 2,7e19 units

Multiplied this becomes 8,1e37 operations a second. This is 2^126 bits
(I didn't aim to get this number!). So with four of those machines you
would exhaust the keyspace of IDEA in just one second.

A box of (3476 km)^3, in which our moon would fit, filled with these
mighty units however would do 1,3e68 operations a second. Equaling 2^226
operations a second. Running this for a hundred years (2^10 seconds)
would just about crack a 237 bit key (could be a hundred years later if
you have bad luck).

Back to the real world; my P150MMX does 1,5e8 operations a second. Not
10^12 or 10^18 ;-) And a circuit the size of an angstrom will probably
never be, maybe a few thousand angstroms. So you could at least
substract 15 bits from your for ever safe number of bits. And it will
never be the size of the moon, so you could gain another 30 bits there.
So that leaves 190 as the ultimate safe number of bits?

Please review these numbers (rougly) and comment,
Thomas

BTW We're not talking about the next few hundred years! We are talking
about the _far_ _far_ future, with a lot of technology, time, money and
resources at our disposal!
-- 
AMD K7 Athlon 650 Mhz! <http://www.bigbrotherinside.com/#help>

PGP key: http://x11.dejanews.com/getdoc.xp?AN=453727376
Email: boschloo_at_multiweb_dot_nl


------------------------------

From: Larry Phillips <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Subject: Re: radioactive random number generator
Date: Sun, 03 Oct 1999 17:40:25 GMT

Jeff Brandenburg wrote:

> Thermal noise:  needs no shielding, needs no permits, causes no
> hysteria

I think I'd rather cause the hysteria. There is an entire subset of
folks that I not only don't give a damn about, but that I am willing to
annoy whenever the opportunity presents itself.

-- 
          Hukt on fonix werkt fer me!

  http://cr347197-a.surrey1.bc.wave.home.com/larry/

------------------------------

From: [EMAIL PROTECTED] (Jeff Brandenburg)
Crossposted-To: sci.electronics.design,sci.electronics.equipment
Subject: Re: radioactive random number generator
Date: 3 Oct 1999 13:10:52 -0400

In article <L1yJ3.4923$[EMAIL PROTECTED]>,
Dave VanHorn <[EMAIL PROTECTED]> wrote:
>
>> As far as I can see, the only reason to construct such a hardware
>> random number generator is the coolness factor.  Sure, anybody
>> can make a noise source with just a resistor and a capacitor,
>> but it takes a real engineer to use a dangerous radioactive source.

^^^ This was sarcasm, right?

>> You could do it in a ridiculously hard way, but then you'd
>> have to compete with things like http://lavarand.sgi.com/
>> and http://www.fourmilab.ch/hotbits/
>
>That's the whole point. An alpha source is totally safe, as long as you
>don't EAT it.

Or inhale it, or get it into your bloodstream.  Of course, I've never
vaporized a component, or jabbed myself on a broken lead. :-)

>The radiation is helium with no electrons.
                 ^"just"?

Um, but, but, beta radiation is "just electrons", and gamma is "just
photons".  I'd really rather not be hit with *anything* above a certain
energy, thankyewverymuch.

(Yes, external alpha is nearly harmless, because it gets stopped by
skin or clothing.  But you won't convince any radiophobes with this
kind of argument!)

>Can you live with a few helium nucleii bouncing off you?

I don't know if "bouncing off" is quite the right way to put it -- more
like "crashing to a halt, breaking lots of chemical bonds along the way."
Of course, our bodies are built to tolerate a lot of that sort of thing --
to tolerate, for example, the damage you're taking every second of your
life from radioactive potassium all through your body.

>Seems likely, as you already are.

I can live with a few hundred grams of metal-encased liquid bouncing
off me, as when I drop an unopened drink can in my lap.  I can even
live with it if I drop it on my toe, although I'll be pretty unhappy.
But if it's traveling at several thousand feet per second when it hits,
it'll probably ruin my whole day.

Similarly, I don't mind a few free electrons drifting into me, and
even getting smacked smartly by a few million million million million
in an electrostatic discharge won't do more than make me cranky.  But
a high-intensity beta emitter is another story.

  Alpha:  blocked by a sheet of paper
  Beta:   blocked by a sheet of aluminum foil
  Gamma:  blocked by a lot of lead or concrete

  Thermal noise:  needs no shielding, needs no permits, causes no hysteria

Of course, one good way to increase thermal noise is by increasing
temperature, and one convenient way to increase the temperature is
from a nice warm chunk of something with a short half-life... :-)
--
        -jeffB (Jeff Brandenburg, Durham, NC)

------------------------------

From: fungus <[EMAIL PROTECTED]>
Subject: Re: Addition/subtraction mod 256 vs. XOR
Date: Sun, 03 Oct 1999 20:45:26 +0200



Mike DeTuri wrote:
> 
> Doing addition mod 256 would make the code harder but I was wondering
> if it this would be of any benefit...
> 

It would make *no* difference to the security.



-- 
<\___/>
/ O O \
\_____/  FTB.

------------------------------


** 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
******************************

Reply via email to