Cryptography-Digest Digest #127, Volume #11      Tue, 15 Feb 00 13:13:01 EST

Contents:
  Re: Does the NSA have ALL Possible PGP keys? (John Savard)
  Re: What are these Rot-45, Rot-13, Rot-5 algorithms? (Tim Tyler)
  Re: Funniest thing I've seen in ages - RSA.COM hacked :) ([EMAIL PROTECTED])
  Re: Does the NSA have ALL Possible PGP keys? (John Savard)
  Re: Predicting the next random number (John Savard)
  Re: Latin Squares (was Re: Reversibly combining two bytes?) (Michael Wojcik)
  Re: Does the NSA have ALL Possible PGP keys? (James Felling)
  Re: ECES Question ! (DJohn37050)
  Re: Predicting the next random number (James Felling)
  Re: Elliptic and Rivest (DJohn37050)
  Re: Basic Crypto Question 3 (wtshaw)
  Re: Basic Crypto Question 3 (wtshaw)
  ECDSA added to DSS (DJohn37050)
  Re: BCH Implementation (Mike Rosing)
  Re: What are these Rot-45, Rot-13, Rot-5 algorithms? (wtshaw)

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

From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 15 Feb 2000 09:15:13 GMT

"tiwolf" <[EMAIL PROTECTED]> wrote, in part:

>Does anyone here really think that any cryto program self made or commercial
>is not broken already or can't be broken given a little effort by the NSA
>geeks. I know that someone might use some type of cryto that might give them
>trouble for a while, but if they really want to I think that the NSA geeks
>can break it.

I _do_ think that there are plenty of ways to encrypt messages so that
cracking them is beyond even the abilities of the NSA.

However, that is specifically _excluding_ more active measures, like
planting bugs inside someone's cipher machine - or PC.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: What are these Rot-45, Rot-13, Rot-5 algorithms?
Reply-To: [EMAIL PROTECTED]
Date: Tue, 15 Feb 2000 15:37:06 GMT

Runu Knips <[EMAIL PROTECTED]> wrote:

: And I wonder what ROT45 should be - because there are only 26
: alphabetic characters ... (ROT13(ROT13(x)) == x for any x).

13 is used since no direction of rotation need be specified.

Rot-5 and Rot-45 don't appear in any references to obscuring text I can find.

Perhaps the answer is that ROT45 is a composite sometimes used in Logo ;-)
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

Counting in binary is like counting in decimal, if you are all thumbs.

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

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.pgp.discuss,alt.security.pgp
Subject: Re: Funniest thing I've seen in ages - RSA.COM hacked :)
Date: Tue, 15 Feb 2000 16:09:18 GMT

In article <88bncu$e4o$[EMAIL PROTECTED]>,
  Bob Silverman <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
>   Jerry Coffin <[EMAIL PROTECTED]> wrote:
> > In article <889455$ivh$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
> >
> > [ ... ]
> >
> > > Will anyone trust YOU now???
> > >
> > > Our website address is www.rsasecurity.com   and has been so
> > > for some time. www.rsa.com  is no longer a valid URL.
> >
> > Here's what Network Solutions says in response to a whois lookup of
> > "rsa.com":
>
> <snip>
>
> >    Record last updated on 06-Nov-1998.
>
> Note the date!  RSA Security changed its name in fall of 1999.
> The database is out of date!
>
> --
> Bob Silverman
> "You can lead a horse's ass to knowledge, but you can't make him
think"

Who do you think has responsibility for keeping these entries up to
date?  The magic Network Solution pixies?  Or maybe it is RSA's
responsibility?

If your company isn't sufficiently competent to update DNS entries
since the change of name, are we to blame? ;)


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

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

From: [EMAIL PROTECTED] (John Savard)
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 15 Feb 2000 09:21:13 GMT

"tiwolf" <[EMAIL PROTECTED]> wrote, in part:

>Mr. Collier I am only thinking that history is filled with governments bent
>on gain the knowledge that men wish to hide. Knowing this do you really that
>governments are really not going to eventually put enough effort into
>breaking the unbreakable. It is only a matter of time and money Mr. Collier.

Maybe or maybe not - in the case of RSA or Diffie-Hellman, there may,
or may not, be mathematical breakthroughs out there to be found with
enough effors.

In the case of symmetric-key methods, they can be made arbitrarily
complicated. If people put enough real effort into keeping their
secrets, they can achieve security against pure cryptanalysis. Key
management is harder to deal with, though.

>PS Once upon a time educated men said that the earth was flat and man would
>never fly with the birds. I am not a scholar, I am however a good observer
>of history and history show us that governments want control.

History also shows us that wanting is not always as good as getting.

But governments can plant bugs, and eavesdrop on RF leakage. _That_,
not the ability to perform inconcievable feats of mathematics, is the
real reason that they might be able to listen in to *almost*
everything they want to.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Predicting the next random number
Date: Tue, 15 Feb 2000 09:23:33 GMT

David A Molnar <[EMAIL PROTECTED]> wrote, in part:

>Is there a way to adjust odds like this on the fly without using PRNGs,
>and without alerting the player that the machine just had a personality
>change? 

Sure. Use a true random number generator to generate numbers from
0000... to .9999... and just change what is done for each of those
numbers instead of changing how a PRNG works.

John Savard (jsavard<at>ecn<dot>ab<dot>ca)
http://www.ecn.ab.ca/~jsavard/crypto.htm

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

From: [EMAIL PROTECTED] (Michael Wojcik)
Subject: Re: Latin Squares (was Re: Reversibly combining two bytes?)
Date: 15 Feb 2000 15:41:00 GMT
Reply-To: [EMAIL PROTECTED]


In article <884ot5$kci$[EMAIL PROTECTED]>, "r.e.s." <[EMAIL PROTECTED]> 
writes:
> "Michael Wojcik" <[EMAIL PROTECTED]> wrote ...
> : "r.e.s." <[EMAIL PROTECTED]> writes:
> : > "Michael Wojcik" <[EMAIL PROTECTED]> wrote ...
> : > : [re generating Latin Squares with three permutations P (one
> : > :  column), R (an ordering of rotations of P), and T (a final
> : > :  permutation of rows)]

> Sorry I didn't catch this earlier, but the number of PRT
> squares is not N!^3, but N!(N-1)!f(N), where f(N)=1 for N<4,
> and f(N)>1 for N>=4. (I haven't been able to deduce the
> complete form of f(N).)  The first two steps, PR, result
> in having filled the columns with the N rotations of a
> selected permutation P.  Thus, col_0 could get filled in N!
> ways, and for each of these there are N-1 ways that col_1
> could get filled, then N-2 ways for col_2, etc, and hence
> N!(N-1)! different PR squares.  "By inspection" we can see
> that for N<4, further permutating the rows by T introduces
> no square not already possible by PR alone, but that when
> N>=4, new possibilities are indeed introduced.  (f(N) is
> clearly not N! -- maybe someone else can see what it is?)

Excellent point -- in brief, some T permutations (reordering the rows
after the columns are constructed by the PR method) produce squares
that are also PR squares, and some T permutations do not (for N >=
4).  f(N) = N! - {number of T permutations that produce other PR
squares, ie. squares where all columns are rotations of one another},
right?  We're interested in T permutations that produce non-PR
squares -- we want to avoid the structure of the PR form in our
combiner -- so let's call those permutations Td, the set of T
permutations that produce a PR square from a given input PR square.
(One obvious member of this set is T={0,1,2,...,N-1}, since it
doesn't reorder the input PR square at all.)

So f(N) = N! - #Td.  I suspect, though, that some elements of Td
depend on the input (at least for sufficiently large N), so that
should really be #Td(P,R).

> [snip example]

> For N>=4 the situation changes such that not all of the
> Lsquares are PR squares, and *presumably* not all PRT
> squares are Lsquares.

Maybe I'm missing something, but why wouldn't all PRT squares be
Latin Squares?

All PR squares are Latin Squares.  The "base column" (P) contains
each element from 0 to N-1 (or 1 to N, if you prefer that numbering)
once and only once.  All other columns are rotations of P, so each of
them contain each element once and only once.

Since each column's degree of rotation is a unique element in R, and
R contains each element once and only once, no columns contain the
same element in the same position; thus all rows contain each element
once and only once.

Since the PR square is a Latin Square, shuffling its rows produces a
Latin Square.  (Shuffling rows can't change how many times a value
appears in a column, and it can't change the composition of a row.)
That's what the T transformation does -- it selects a permutation of
the rows of the input PR square.


--
Michael Wojcik                          [EMAIL PROTECTED]
AAI Development, MERANT                 (block capitals are a company mandate)
Department of English, Miami University

Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".

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

From: James Felling <[EMAIL PROTECTED]>
Crossposted-To: comp.security.pgp,misc.survivalism
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: Tue, 15 Feb 2000 10:44:34 -0600



tiwolf wrote:

> No I am saying that  once man thought the  earth was the center of the solar
> system, now time, thought , research and a good amount of money show us
> differently. I am also not saying that all codes are broken, I am only
> saying that the code that are not yet broke will in time be broken.

Why do you claim that "any code can be broken"?  I can accept the statement
given a code X  there exists no way of determining whether or not a break can or
will exist at some point in the future.  However, I do not accept the statement
that all presently existing codes must therefore possess a break.( By break I
mean an attack against it that is faster than  brute force)


> The only
> code that is will never be broke is the code that man never develops.

or one that a break of is equivalent to solving an unsolvable (by any means
other than trying all the possibilities) problem

>
>
> PS Have any of you ever considered that the code breakers of old sat around
> looking at random bits of intelligence until they were able to find
> something that fit and then over time pieced together a key to the code they
> could not break before. Most of this was not done with computer yet humans
> with paper, slide rules, pencils, and a lot of time did it. Do you really
> think that people today are not willing to put in the time to break codes
> that you believe are unbreakable?

No, I fully expect that people will produce new attacks versus almost all codes
in existence, and that many cypehrs will fall to these attacks.  But, just
because people want a break and work toward such a goal, this does not mean that
their success is guaranteed. There were people who wanted straightedge and
compas constructions for any number of geometric forms, and for many many hours
briliant minds worked toward just such a construction, but no one succeded, and
indeed it was eventually demonstrated that such constructions were impossible.
This may be the case with some presently existing cyphers, or it may not, but
you cannot assert that "throw enough briliant minds and money at any code and it
will be broken".

<sniped previous posts>


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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: ECES Question !
Date: 15 Feb 2000 17:16:59 GMT

Look at ECIES in P1363a draft.
Don Johnson

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

From: James Felling <[EMAIL PROTECTED]>
Subject: Re: Predicting the next random number
Date: Tue, 15 Feb 2000 11:15:45 -0600



David A Molnar wrote:

> John Savard <[EMAIL PROTECTED]> wrote:
> > My fault for not reading carefully enough...I thought he just said
> > "ANY random number generator". (Of course, there are those video slot
> > machines; I'm not sure, but I would suspect _they_ might use PRNGs.)
>
> One interesting question -- there are casinos in Las Vegas which
> advertise claims such as :
>
> "100+% payout on X% of our slot machines!"
>
> which, I think, means something along the lines of "if you play one of
> the machines in the lucky X% of our machines over a long period of time,
> you will tend to make back your money and more."
>
> One way to guarantee these odds might be to use PRNGs and then adjust
> the stream in order to get the desired properties. Indeed, we had
> several high-profile gaming fraud cases in which slot machine repairmen
> ended up adjusting machines in their favor. (I live in Vegas, but I'm
> a transplant. I don't actually know anything about the city).
>
> So you'll note that which machines are in the lucky X% of slot machines
> are not specified in the advertising claim. Sometimes you can see people
> in casinos hopping from machine to machine, hoping that they will find
> one of the 100+ payout machines.
>
> The interesting question : what if the X% of lucky machines isn't fixed?
> What if the "lucky" machines exist, but the choice of lucky machines
> changes? often? So often that you'll be on a lucky machine, play, and
> then the machine changes and is no longer lucky?
>
> Using PRNGs, you update the PRNG in the machine to do your new bidding.
> Is there a way to adjust odds like this on the fly without using PRNGs,
> and without alerting the player that the machine just had a personality
> change?
>
> Thanks,
> -David

Annother possibility is the following.

If you have N slot machines set to payout at 100% then what happens is over
the lifetime of a slot machine some of the machines will payout more than
100%, and some less than 100% thus a valid claim in this case is that some
percentage of our machines pay out at better than 100%, and if the variance
is large enough it amy even be possible to have a very small house margin of
e s.t. the michines payout at (100-e) on average, but statisitcs will show
that some percentage of the machines over their lifetime paid out at better
than 100%.

It is also fairly easy to cook a slot machine to payout at better than 100%
without it being easily noticable to the players

assume you have a machine that pays out at even.make the odds of one of the
fairly small and high probablity payouts better by making it  payout
(1+2^-10) times as often.  This machine will pay out at better than 100% on
average, but I defy you to notice this behavior even upon long observation(
unless you have a photographic memory, and /or are keeping detailed notes).
Heck, you set the other machines to payout (1-2^-10) times as often on the
small payout, and as long as you have more of these taker machines than
payers, you will make money( Not much money, but...) and the difference in
behavior will be such that no normal person will notice.



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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: Re: Elliptic and Rivest
Date: 15 Feb 2000 17:19:53 GMT

Also see IEEE P1363 website and www.certicom.com for EC papers
Don Johnson

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Basic Crypto Question 3
Date: Tue, 15 Feb 2000 10:27:03 -0600

In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:

> David Wagner wrote:
> > Well, you need to use independent keys if you are to have any hope
> > of robustness [1].
> 
> My point is that key "independence" is crucial and not automatic.
> It needs to be *proven* for the particular concatenation one has
> in mind.  Otherwise, one is just trusting to luck.

It may well be that weakness of certain combinations are best seen with
other than unique keys.  Knowing the answers is not a penalty, but an
advantage in trying to understand interaction.  It may be that there are
not similar keys, but complementary keys that conspire against full
combined strength.
-- 
Let's all sit back an watch the inhabitants of the political zoo 
perform in three rings.  It's more exciting than soap operas.  Then 
vote out anyone who has been in long enough to abuse things.  

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: Basic Crypto Question 3
Date: Tue, 15 Feb 2000 10:20:49 -0600

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(John Savard) wrote:


> 
> - other than the IV noted above, the cipher must not lengthen messages
> submitted to it; where the input is a random n-bit message, the output
> must also be a random sequence of n bits (the equivalent condition
> applying to non-binary encryption, _pace_ W. T. Shaw)
> 
I appreciate the inclusion of other information units as real alternatives.

About lengthening, it is not good to get something wastefully long as a
result of encryption, but by limiting ciphertext absolutely, you
excommunicate ciphers which might be stronger than your other choices.  If
you are married to the idea that an artificial ceiling need be kept for
strength of an individual cipher, you miss algorithms that are better
choices for encryption.

But, given really strong encryption, you need not worry about other
ciphers to add strength, but you still can entertain piling on.  

However, you must be especially careful with static block ciphers so that
you don't by default run into yourself out there in the woods and take a
longer route to get to your destination than is needed, or in particular
circumstances, find yourself not far from where you began.
-- 
If Al Gore wants to be inventor of the internet, complain that he 
did a lousy job.  If he admits to not doing much, complain that he 
is a slacker. Now, do we want him in charge of security?

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

From: [EMAIL PROTECTED] (DJohn37050)
Subject: ECDSA added to DSS
Date: 15 Feb 2000 17:23:25 GMT

ECDSA has been added to DSS.  See www.nist.gov.
Don Johnson

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

From: Mike Rosing <[EMAIL PROTECTED]>
Subject: Re: BCH Implementation
Date: Tue, 15 Feb 2000 11:39:37 -0600

[EMAIL PROTECTED] wrote:
> 
> Hello,
> 
> My gold is to implement BCH Error detection and correction inside FPGA.
> 
> 1. I would like u to help me find information about BCH Error detection
> and correction.
> 2. If any one can direct me to VHDL code for that implementation.
> 3. I don't mind to buy a VHDL core for implement if over FPGA, So if any
> one know a company that sale this kind of core please direct me to there
> site.
> 
> I will really appreciate if any one will help me.

Try these guys (from the Xilinx web site):

Area of Expertise

       N-ISDN (V110, V120, HDLC) 
       B-ISDN (AALx, Utopia) 
       Digital Signal Processing (FFT, FIR) 
       Error Coding/Decoding (Reed-Solomon, Viterbi, BCH, Turbo) 
       Ciphering 
       Application Specific Processors 
       Processor related logic (MMU, DMA, Interrupt control) 
       Telecom Switches 
       Serial interfaces (uart, I2C, SPI) 

 Contact Partner

 INTRAX Engineering
 Kollegestraat 75
 2440 Geel
 Belgium, Europe
 Email: [EMAIL PROTECTED]
 URL: www.intrax.be
 Tel: +32 14 590 475
 Fax: +31 32 14 506 007

Patience, persistence, truth,
Dr. mike

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

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: What are these Rot-45, Rot-13, Rot-5 algorithms?
Date: Tue, 15 Feb 2000 11:07:38 -0600

In article <[EMAIL PROTECTED]>, Runu Knips
<[EMAIL PROTECTED]> wrote:
> 
> And I wonder what ROT45 should be - because there are only 26
> alphabetic characters ... (ROT13(ROT13(x)) == x for any x).

I think I was first with that one: Feb 17, 1996 is the date I registered
the application that contained it and first began to domestically
distribute it.

ROT45 deals with the 90 characters beginning with ASCII-33, 32 being the
non-joining space. Characters123-126, {|}~, are not used, so they can be
used as control/formatting characters, which I find handy.  The uppercase
set is centered in the range, meaning that the uc behaves exactly like
ROT13 in ROT45; lc and other characters do not.

There is also ROT47, which somone else did, that works directly with the
94 characters, ASCII 33-126.

Source, did anyone say source?  C, did you say? I suppose that for the
time for the PC's, I'll have to settle with dumb console applications,
keyboard input and file output.  I guess that I will have the code to post
for doing ROT13, INV26, and ROT45 sometime this week, other things
permitting.  I would rather write code than copy it, and I have my own
style, as I am unimpressed by those that value code by how many sparse
lines it contains.
-- 
Let's all sit back an watch the inhabitants of the political zoo 
perform in three rings.  It's more exciting than soap operas.  Then 
vote out anyone who has been in long enough to abuse things.  

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


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