Cryptography-Digest Digest #629, Volume #11      Tue, 25 Apr 00 13:13:01 EDT

Contents:
  Re: The Illusion of Security (Geoff Lane)
  Re: The Illusion of Security (Tom St Denis)
  Re: GSM A5/1 Encryption (Ian Goldberg)
  #sci.crypt on efnet. ("Simon Johnson")
  PLEASE STUDY MY INTELLIGENC NOTES CAREFULLY .. THANKS .. 
http://homestead.virtualjerusalem.com/waeg/Diaries.html ([EMAIL PROTECTED])
  Re: sci.crypt think will be AES? ([EMAIL PROTECTED])
  Re: AES Style CAST Cipher (csybrandy)
  Re: papers on stream ciphers ("Scott Fluhrer")
  Re: Requested: update on aes contest (Paul Koning)
  Re: Requested: update on aes contest (Paul Koning)
  Re: sci.crypt think will be AES? (Paul Koning)
  H. Riesel's book (JCA)
  Re: factor large composite ([EMAIL PROTECTED])
  Re: sci.crypt think will be AES? (Tom St Denis)
  Re: How relieble is HCE-SHA ? (Diet NSA)
  Re: factor large composite (Tom St Denis)
  Re: sci.crypt think will be AES? ([EMAIL PROTECTED])
  Re: sci.crypt think will be AES? ([EMAIL PROTECTED])
  Re: #sci.crypt on efnet. ([EMAIL PROTECTED])
  Re: new Echelon article (wtshaw)
  Re: factor large composite ([EMAIL PROTECTED])
  Re: Secret splitting for kids' treasure hunt (Mike Rosing)
  Re: #sci.crypt on efnet. ("Simon Johnson")
  Re: H. Riesel's book (Jim Gillogly)

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

From: [EMAIL PROTECTED] (Geoff Lane)
Subject: Re: The Illusion of Security
Date: Tue, 25 Apr 2000 13:15:15 +0100

>> The secret lies in the Non Linear F Function...This can be decomposed
>> into Algebraic Linear Primitives...and the Key can be recovered
>> relatively easily...The Backdoor Function...

Err..., can a non-linear function be composed of a finite number of linear
functions?  Fourier analysis would imply not.  Unfortunately an approximate
solution will not result in a valid decrypt.


-- 
/\ Geoff. Lane. /\ Manchester Computing /\ Manchester /\ M13 9PL /\ England /\

Today's Excuse:  The keyboard isn't plugged in

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: The Illusion of Security
Date: Tue, 25 Apr 2000 13:35:39 GMT



Geoff Lane wrote:
> 
> >> The secret lies in the Non Linear F Function...This can be decomposed
> >> into Algebraic Linear Primitives...and the Key can be recovered
> >> relatively easily...The Backdoor Function...
> 
> Err..., can a non-linear function be composed of a finite number of linear
> functions?  Fourier analysis would imply not.  Unfortunately an approximate
> solution will not result in a valid decrypt.

... over a diversity of inputs.

If I understand the scene right, linear analysis looks for some "linear"
equation that holds for some of the inputs/outputs pairs  with some
probablity..  Like F(x, k) = x ^ k, prob = 1/4, can be used to extract
the key using about 16 or (1/(1/4)^2) pairs right?

Tom
--
Want your academic website listed on a free websearch engine?  Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.

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

From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: Re: GSM A5/1 Encryption
Date: 25 Apr 2000 14:31:19 GMT

In article <8dtlal$[EMAIL PROTECTED]>,
Guy Macon <[EMAIL PROTECTED]> wrote:
>Given the above assumptions, you can achieve a slight increase in
>your overall security by adding a random number of random bits to
>the beginning and end of your message before doing any encoding.
>
>The cost of doing this is very low, and can be chosen to be as low
>as the user desires.  If 1% at the beginning and at the end is too
>much, make it 0.1%.
>
>This addition will work with all known crypto programs.  They all
>accept plaintext, and will accept plaintext that is partially
>random bits.
>
>In most cases it is not necessary to remove the random data when
>the message is decoded.  It is trivial for a human to differentiate
>random data data in print or audio from an intelligable message.

What I think Guy is missing is that GSM uses A5 to encryt 228 bits
at a time; each 228-bit frame (that's 114 bits in each direction)
is encrypted *independently*, not as part of a longer stream.  This
is done so that dropped frames don't desynchronize the encryption.

So if you were to add 1% random padding at the beginning and end of
the message, that would be adding 2 bits to *each frame* (1 in each
direction), not a second or so at the beginning of the conversation.

The value this would add to thwart a known-plaintext attack (silence
frames, etc.) is obviously trivial: there are now just *two* kinds
of silence frames: one with a 0 bit added, and one with a 1 bit added.

If you were to add a significant number of padding bits to the silence
frame, you get David's 15% overhead estimate.  If you just add the
padding to the beginning of the conversation, you gain nothing, since
changing only the first frame of the GSM-encrypted stream doesn't
affect the rest of the stream at all.

Hold on a sec.  A5 is a *stream cipher* in the first place.
Adding random padding to *any part* of the message is useless!  Assuming
the attacker knows *where* the padding was added, he just ignores the
corresponding encrypted bits.  (And if the attacker doesn't know what
bits are message and what are padding, how does the recipient?)

A stream cipher like A5 has the property that flipping a bit in the
plaintext just flips that same bit (and no others) in the ciphertext.

So what Guy writes above may make sense for general cryptosystems, but
not in the particular case of A5 and GSM.

   - Ian

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

From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: #sci.crypt on efnet.
Date: Tue, 25 Apr 2000 16:19:53 -0700

Hi, i've opened a chat-channel on Efnet. Its is named, quite logically,
#sci.crypt
Its success depends on you! the more of you that participate the more
successfull the channel will be.

Like sci.crypt it's an open forum for discussion on the wonderful science of
cryptography :). I would be really greatful if the seasoned professionals on
this newsgroup would lend a hand :)

Thanxs, with anticiption

S Johnson.

--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!



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

From: [EMAIL PROTECTED]
Crossposted-To: alt.politics.org.cia,soc.culture.russian,soc.culture.nordic
Subject: PLEASE STUDY MY INTELLIGENC NOTES CAREFULLY .. THANKS .. 
http://homestead.virtualjerusalem.com/waeg/Diaries.html
Date: Tue, 25 Apr 2000 15:15:40 GMT




http://homestead.virtualjerusalem.com/waeg/Diaries.html

I have about 100 times more, but not yet posted on the Internet /
USENET.

Yours,

Markku


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

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

From: [EMAIL PROTECTED]
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 15:30:21 GMT

In article <[EMAIL PROTECTED]>,
  Tom St Denis <[EMAIL PROTECTED]> wrote:

<SNIP>

> To be honest I can't see rijndael or serpent be that awful on most
> platforms.  I just think Twofish is more versatile.  If it were upto
me
> I would pick them all :)  But then we would be lost...

(NOTE: I'm not a cryptographer, but an end user of ciphers & encryption
products).

I'm preparing a comment for NIST, but from NIST & Gladmans reports on
speed Serpent does fair very well when you consider:

  1) Hardware - Serpent faster by a fair margin.

  2) Encrypting small amounts of data (where block encryption costs are
overshadowed by key set-up costs).  IMHO, bulk encryption is relatively
rare compared to the encryption of small number of blocks (think ATM,
IPSEC etc - these are the environments where throughput really matters.

  3) Smartcards.  Serpent thought to be second fastest.

Remember that the NIST criteria specified that security was a primary
requirement, not speed.  Everyone seems to agree that Serpent appears
to be the most secure of the candidates AND is acceptably fast (i.e.
beats the speed of 3DES on the NIST chosen platforms).

It's also interesting that it is thought that Serpent has the most
scope for improving speed with optimisation (by finding better boolean
expressions for the S-Box(s)).

My preference (best first): Serpent, Rijndael (+3 rounds), Twofish, RC6
& MARS.


AES will likely protect data for ~100 years or so - surely it pays to
be conservative when choosing!


Regards,

Sam Simpson
IT Operations Manager
MIA Ltd


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

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

From: csybrandy <[EMAIL PROTECTED]>
Subject: Re: AES Style CAST Cipher
Date: Tue, 25 Apr 2000 11:27:46 -0400
Reply-To: [EMAIL PROTECTED]

I think that you need to have either Mandrake or Stampede Linux in order
to compile to a pentium or above architecture.  Both of these are
optimized for the pentium architectures.  Mandrake also works on
Athlons, so it may be a better choice for all AMD chips in general. 
With Mandrake, there are a couple varieties so you should make sure you
get the optimized version.

csybrandy

Manuel Pancorbo wrote:
> 
> [Tom StDenis]:
> >
> > I also did some timing tests and the same  C ref optimized via DJGPP
> > (-O3 -mpentium) gives 10 Mbyte/sec performance, which is not too bad.
> > That translates roughly to 650,000 blocks a second, or 38.46 cycles/byte
> > on my K6-II 400mhz.  I know this is not in the 20 cycle/byte range, but
> > I bet with tons of ASM optimizations (I can name a few obvious ones) 30
> > cycles/byte will be easy to obtain.
> >
> 
> Oh! 20 cycle/byte it's a lot! where did you obtain this number? I think 10
> times (200 cycle/byte) is good enough for most applications.
> 
> I did some timing tests on my own cipher. I have a K6-II 350 and an old
> borland C compiler (for DOS, with the abbility to make windows 3.1 dll's).
> With it, in ANSI-C mode, I obtained 1800 cycles/byte. Very bad.
> Furtherly, on the same computer,  I compiled the program in Linux with 'gcc'
> ANSI and with optimizations "-O2" and "-m486" (no trace of "-mpentium" I saw
> on my 'gcc' manual) and I obtained 600 cycles/byte (supposing that all CPU
> power was devoted to the test; I'm not sure about this).
> 
> So I wonder:
> 1) if 'gcc' compiled the code in -true- 32 bit fashion. This is essential
> for my algorithm. Perhaps I have not the appropiate 'gcc' version; (I'm
> neither an experienced programmer, neither a full-time Linux user)
> 2) if C++ compilation is desireable in order to obtain maximum performance.
> My Linux instalation doesn't have the C++ part of 'gcc' but I could obtain
> it.
> 3) by the way, how many 32-bit register are disposable to the programmer
> with this CPU (I mean, how many 'register' variables can be used with
> confidence).
> 
> Help will be appreciated. Also, any further suggestion about compilers,
> optimization, time testing, etc
> 
> --
> ____________________________________________________________________________
> _________
> 
>  Manuel Pancorbo
>  [EMAIL PROTECTED]
>  "...
>    Más vale aprender una sola línea de Ciencia
>    que postrarse cien veces en oración. (Corán)
> 
>    Pli valoras lerni ech nur unu linion de Scienco
>    ol preghe genui cent fojojn. (Korano)
>  ..."
> ____________________________________________________________________________
> _________

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

From: "Scott Fluhrer" <[EMAIL PROTECTED]>
Subject: Re: papers on stream ciphers
Date: Tue, 25 Apr 2000 08:42:12 -0700


Richard Parker <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Tom St Denis <[EMAIL PROTECTED]> wrote:
>
> > Looking for papers about stream ciphers.  It seems block ciphers are the
> > norm lately...
> >
> > Looking for prng/stream ciphers.  Preferably not based on lfsrs....
>
> In addition to the papers mentioned by David Hopwood, you may wish to take
a
> look at SEAL 3.0:
>
>   P. Rogaway and D. Coppersmith, "A Software-Optimized
>   Encryption Algorithm," Journal of Cryptology, v. 11, n. 4,
>   1998, pp. 273-287.
>   <http://www.cs.ucdavis.edu/~rogaway/papers/seal-abstract.html>

Just a word of warning if you are looking for stream ciphers to implement in
your crypto toolkit -- Seal is patented by IBM, and I don't think they have
any 'free for academic use' policies on their patents...

--
poncho




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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Tue, 25 Apr 2000 11:58:22 -0400

Jerry Coffin wrote:
> ...
> The question isn't about A5's strength, but its fundamental design:
> it wasn't anything like DES, because DES simply wouldn't have worked
> in that situation, regardless of its strength.

I don't see why that's so.  There was a discussion recently
about why the application required a stream cipher, but
the argument completely failed to hold water.

        paul

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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: Requested: update on aes contest
Date: Tue, 25 Apr 2000 12:02:34 -0400

"Trevor L. Jackson, III" wrote:
> 
> Paul Koning wrote:
> 
> > Available good security beats unavailable perfect security
> > any day.
> 
> I'm not disputing your conclusion (I agree with it), but I'm curious as to how
> you reached it.  Is "IPsec == good security" an assumption or a conclusion
> and, if a conclusion, how did you reach it?

Some of each.  A conclusion based on the same sort of 
argument applicable to any cryptosystem: absence of
data indicating it's broken, in spite of a substantial
amount of effort to find such data.

There are some old papers about weaknesses in IPSec (e.g.,
by Steve Bellovin) that are now cured.  (Well, mostly;
for political reasons you're still allowed to misconfigure
things, sigh.)  And while the recent paper by Schneier et al.
brought up a whole pile of criticism, I don't believe it
actually showed any weaknesses.  (The comments were
mostly of the form "this is more complex than it ought 
to be".  Yes, sure, but such is the committee process.)

        paul
-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, D-20853
! Lucent Corporation, 50 Nagog Park, Acton, MA 01720, USA
! phone: +1 978 263 0060 ext 115, fax: +1 978 263 8386
! email: [EMAIL PROTECTED]
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "A system of licensing and registration is the perfect device to deny
! gun ownership to the bourgeoisie."
!       -- Vladimir Ilyich Lenin

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

From: Paul Koning <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 12:04:22 -0400

Runu Knips wrote:
> 
> Tom St Denis wrote:
> > Why I like Twofish.  It's fast, it's compact, it's versatile (speed/size
> > tradeoffs), it's designed sanely.  It's also very good choice for
> > hardware.  It's also secure the best attack breaks (without whitening)
> > only 6 rounds and doesn't work against the full algorithm.
> 
> Hey another Twofish fan ! :)
> 
> I'll like it most of all AES candidates, too. You've forgot another
> point: its the AFAIK only one which is free NOW (no matter if it
> will be the AES winner, or not).

No; I think the same is true for Rijndael and Serpent.

I have a silly reason for liking Rijndael -- the name... :-)

        paul

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

From: JCA <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: H. Riesel's book
Date: Tue, 25 Apr 2000 08:59:35 -0700


    Does anybody know why B&N are selling Riesel's "Prime Numbers and
Computer Methods for Factorization" so cheap? It seems to be exactly the

same edition and binding as the one that goes for almos $70 in B&N
itself and
elsewhere.

    Are there perhaps some subtle differences I am not aware of?




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

From: [EMAIL PROTECTED]
Subject: Re: factor large composite
Date: Tue, 25 Apr 2000 16:31:26 GMT

David Blackman <[EMAIL PROTECTED]> wrote:
> None of these methods have any hope of factorising a 2048 bit number at
> all on current hardware, except maybe elliptic curve might fluke a
> solution if you get incredibly lucky.

ECM isn't going to fluke a solution either with the size curve you'd
need, I shiver just thinking about it. ;) I do wonder about the fluke
method alot though.

Talking just about 2048 bit RSA keys now, we know that it has two
factors. That means they're both smaller than the square root
(obviously), about the same size (because it's an RSA key), and
sufficiently big enough that the two of them mulitplied together
produce a number 2048 bits long (duh).

My questions are:

1. Assuming we skip the primality test (icky, expensive) and just do
trial divisions of numbers in the search space at random, how many
potshots are we looking at here?

2. On current hardware, what's a reasonable guesstimate to the amount
of divisions you could do in a given time?

3. Based on the above, how many of these machines would I need to have
guessing to see a reasonable probability of hitting the factor in my
lifetime?

My gut tells me the state lottery is a much better bet, I'm just
curious how much better.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 16:31:32 GMT



Paul Koning wrote:
> 
> Runu Knips wrote:
> >
> > Tom St Denis wrote:
> > > Why I like Twofish.  It's fast, it's compact, it's versatile (speed/size
> > > tradeoffs), it's designed sanely.  It's also very good choice for
> > > hardware.  It's also secure the best attack breaks (without whitening)
> > > only 6 rounds and doesn't work against the full algorithm.
> >
> > Hey another Twofish fan ! :)
> >
> > I'll like it most of all AES candidates, too. You've forgot another
> > point: its the AFAIK only one which is free NOW (no matter if it
> > will be the AES winner, or not).
> 
> No; I think the same is true for Rijndael and Serpent.
> 
> I have a silly reason for liking Rijndael -- the name... :-)
> 
>         paul

My reasons for liking Twofish extend to the name too.  In reality I
think all five winners are good ciphers, but Twofish is just catchier.

Tom
--
Want your academic website listed on a free websearch engine?  Then
please check out http://24.42.86.123/search.html, it's entirely free
and there are no advertisements.

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

Subject: Re: How relieble is HCE-SHA ?
From: Diet NSA <[EMAIL PROTECTED]>
Date: Tue, 25 Apr 2000 09:33:39 -0700


In article <
[EMAIL PROTECTED]>, Fedor
Utenkov <[EMAIL PROTECTED]>
wrote:

>I'd like to use this cipher to send data over internet. It used
in the
>CGI::EcryptForm package for perl.
>I know a little about this cipher. Implementation is very
simple.
>It seems to me it so relieble as far relieble random generator
used
>in.So the next question is how relieble this cipher with
standard perl
>rand() ?
>Please, if somebody know some evidence or have url where to
read drop a
>line.


Info on perl modules, etc. can be found at
http://www.cpan.org   or you might try
searching   http://www.av.com


" V hfdt afogx nfvw ufo axb (o)(o) "   - Gtnjv
====================================================
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


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

From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: factor large composite
Date: Tue, 25 Apr 2000 16:38:29 GMT



[EMAIL PROTECTED] wrote:
> 
> David Blackman <[EMAIL PROTECTED]> wrote:
> > None of these methods have any hope of factorising a 2048 bit number at
> > all on current hardware, except maybe elliptic curve might fluke a
> > solution if you get incredibly lucky.
> 
> ECM isn't going to fluke a solution either with the size curve you'd
> need, I shiver just thinking about it. ;) I do wonder about the fluke
> method alot though.
> 
> Talking just about 2048 bit RSA keys now, we know that it has two
> factors. That means they're both smaller than the square root
> (obviously), about the same size (because it's an RSA key), and
> sufficiently big enough that the two of them mulitplied together
> produce a number 2048 bits long (duh).

They are not both smaller then the square root.  Take 7 * 11 = 77,
|sqrt(77)| = 8.77...

> 
> My questions are:
> 
> 1. Assuming we skip the primality test (icky, expensive) and just do
> trial divisions of numbers in the search space at random, how many
> potshots are we looking at here?

Well it depends on the distance between them.  It's totally easy to have
a space of 2^256 between the smallest factor and the integer square
root.  This makes things like fermats method (fastest integer factoring
method for small distance factors) very inpractical.

> 2. On current hardware, what's a reasonable guesstimate to the amount
> of divisions you could do in a given time?

Not a heck of alot.

> 3. Based on the above, how many of these machines would I need to have
> guessing to see a reasonable probability of hitting the factor in my
> lifetime?

Doing trial division, probably on the order of 10^50 (just a wild
guess), even then you can't build that many...
 
> My gut tells me the state lottery is a much better bet, I'm just
> curious how much better.

You will win the lottery 1000 times before factoring a 2048 bit number.

Tom

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

From: [EMAIL PROTECTED]
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 16:39:14 GMT

David Blackman <[EMAIL PROTECTED]> wrote:
> RC6 and Rijndael don't seem to have enough "headroom", ie not enough
> extra rounds above the number that have been (partially, theoretically)
> cracked so far. Maybe Mars as well. That might be a worry if we want AES
> to stay secure for a long time. Rijndael is otherwise fast and nice, so
> Rijndael with a few more rounds would make sense, as suggested by Bruce
> Schneier and probably others. I'm not sure if that kind of change is
> allowed at this late date.

If memory serves, DES was found to be just one round above an attack
discovered in the 80s, so in some cases this is good design. ;)

Really though, AES has been a boon for everyone, I think. Industry
will definately benefit from a replacement for DES. And the software
world is definately the big winner, with a handful off unencumbered,
secure block ciphers having emerged.

In short, I'm so far out of my league analysing any at this stage,
that I'm trusting everyone else to pick one for me. But I plan to mix
and match the others in non-conforming products.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED]
Subject: Re: sci.crypt think will be AES?
Date: Tue, 25 Apr 2000 16:46:12 GMT

Joseph Ashwood <[EMAIL PROTECTED]> wrote:
> From this I conclude that there is a very real limit of the
> maximum number of useful rounds of a cipher. This limit is
> very real, and to my knowledge noone has computed the limit
> for any modern cipher in terms of rounds.

It's an interesting argument, but I suspect the number you're fishing
for is huge. A more serious argument is that the vast majority of
ciphers run slower with more rounds. Apparantly, 16 was optimal for
DES, although it arguably may have been a teeny bit stronger with 20
or 40. I suspect deep down that the same gene controlling ludicrous
key sizes also contributes to ludicrous rounds. 

Seriously though, I realise there's alot of design, but deep down in
my gut, I get a bad feeling when rounds are added to an
algorithm. It's a horrible analogy, but I'd much rather put a better
lock on my door if someone broke in than keep adding additional ones.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED]
Subject: Re: #sci.crypt on efnet.
Date: Tue, 25 Apr 2000 16:49:22 GMT

Simon Johnson <[EMAIL PROTECTED]> wrote:
> Hi, i've opened a chat-channel on Efnet. Its is named, quite logically,
> #sci.crypt

I'm not a big irc user (ok, I never use it), but I feel compelled to
point out the open project network. Granted, it's aimed at channels
for open-source software, but it still may be less plagued by sex
channels, ads, and idiots than the big networks.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED] (wtshaw)
Crossposted-To: 
alt.politics.org.cia,alt.politics.org.nsa,alt.journalism.print,alt.journalism.newspapers
Subject: Re: new Echelon article
Date: Tue, 25 Apr 2000 10:04:05 -0600

In article <[EMAIL PROTECTED]>, Diet NSA
<[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]>
> , "Trevor L. Jackson, III" <
> [EMAIL PROTECTED]> wrote:
> 
> >Legality has little or nothing to do with Justice, that's why
> she wears a
> >blindfold.
> >
> 
> In reality, "justice" and "legality" are
> relative concepts which have to be
> considered within the appropriate
> context. What may be illegal or unjust in
> one country may not be such in another
> country.
> 
The blindfold represents impartiality, and has everything to do with
justice, where "show me the money" should have no place.  Justice is the
property that is mandated to be available to all of us, regardless of
station. Something that is "legal" but unjust should not pass the hurdle
of the courts, whose main duty is fairness. Truth and Justice exist as the
Law only when it is fair; that is the American Way. 

Where are you, Superman? (He does not need a blindfold.)
-- 
(x)(r)(d)[d][c]  [s]<x>[i]<o>[g]  <a><n>

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

From: [EMAIL PROTECTED]
Subject: Re: factor large composite
Date: Tue, 25 Apr 2000 16:52:23 GMT

Tom St Denis <[EMAIL PROTECTED]> wrote:
> They are not both smaller then the square root.  Take 7 * 11 = 77,
> |sqrt(77)| = 8.77...

Ugh. You're, of course, correct. 

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: Mike Rosing <[EMAIL PROTECTED]>
Crossposted-To: misc.kids
Subject: Re: Secret splitting for kids' treasure hunt
Date: Tue, 25 Apr 2000 11:00:42 -0500

Andru Luvisi wrote:
> 
> I've been mulling over a little idea for a four kid treasure hunt.
> I'm offering it here in case anyone else is interested, and also in
> the hopes that someone might be able to come up with an easier method
> for the kids to combine the parts of the secret.
[...]

> For each pad, generate a sheet that contains 26 rows, where the first
> row is the pad, and every other row is just one letter ahead of the
> row above it.  Now, make N-1 templates, which each contain as many
> columns as the message, and all of which start with a row of all a's
> and end with a row of all z's.
> 
> To combine the secrets, you need a hand held single hole punch.  Lay
> the sheets on the table in any order.  Pick up a template.  In each
> column of the template, punch a hole through the letter which appears
> in the first row and the corresponding column of the first sheet.
> Place the first template over the second sheet.  Now, take the second
> template, and in each column, punch a hole through the letter which is
> showing through the hole in the first template in the matching column.
> Place the second template over the third sheet.  Continue this process
> until you lay the N-1th template on the Nth sheet, and read the
> message through the holes.

This is really a good way for the kids to do things.  I know my kids
would love it.  You might want to have more than 1 hole punch to reduce
arguments :-)

> I hacked together a short perl script (included below) to split
> secrets and make the sheets and templates for me.  The messages need
> to be fairly short in order to be able to reach all of the columns
> with the hole punch.  For serious uses, you may want to use a better
> PRNG, such as arcfour, Linux's /dev/random, or Yarrow from Counterpane
> Labs.  I'm happy with using rand() because in my threat model, my
> adversaries have no knowledge of advanced mathematics, they do not
> have access to any computing equipment, and the useful lifespan of the
> data is only a few hours.

:-)

Thanks for posting this, it looks like a fun idea!

Patience, persistence, truth,
Dr. mike

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

From: "Simon Johnson" <[EMAIL PROTECTED]>
Subject: Re: #sci.crypt on efnet.
Date: Tue, 25 Apr 2000 18:05:06 -0700



--
Hi! I'm a signature virus! Copy me into your signature file to help me
spread!
<[EMAIL PROTECTED]> wrote in message
news:m0kN4.58287$[EMAIL PROTECTED]...
> Simon Johnson <[EMAIL PROTECTED]> wrote:
> > Hi, i've opened a chat-channel on Efnet. Its is named, quite logically,
> > #sci.crypt
>
> I'm not a big irc user (ok, I never use it), but I feel compelled to
> point out the open project network. Granted, it's aimed at channels
> for open-source software, but it still may be less plagued by sex
> channels, ads, and idiots than the big networks.
> --
> Matt Gauthier <[EMAIL PROTECTED]>

I understand you're concerns, however they're unfounded, EFNET is pretty
clean in that department I think most will aggree. And the day porn gets
into any of my chat-channels will be the day I burn Applied Cryptology and
my PC :)





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

From: Jim Gillogly <[EMAIL PROTECTED]>
Crossposted-To: sci.math
Subject: Re: H. Riesel's book
Date: Tue, 25 Apr 2000 17:04:59 +0000

JCA wrote:
> 
>     Does anybody know why B&N are selling Riesel's "Prime Numbers and
> Computer Methods for Factorization" so cheap? It seems to be exactly the
> 
> same edition and binding as the one that goes for almos $70 in B&N
> itself and
> elsewhere.
> 
>     Are there perhaps some subtle differences I am not aware of?

I just got my copy from Barnes & Noble.  It's the 2nd edition, Birkhauser
Boston 1994, hardbound with green and white cover.  It appears to be the
Real Thing.  It has a "Special Value - $14.99" sticker on the front.  I'd
guess they were overstocked, but who knows.

Good deal!
-- 
        Jim Gillogly
        Highday, 5 Thrimidge S.R. 2000, 17:02
        12.19.7.2.15, 7 Men 18 Pop, First Lord of Night

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


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