Cryptography-Digest Digest #701, Volume #10       Tue, 7 Dec 99 21:13:01 EST

Contents:
  PCI Cryto Card (Arthur Dardia)
  Re: NSA should do a cryptoanalysis of AES (Tim Tyler)
  Breaking NCipher smartcard system ([EMAIL PROTECTED])
  M-Box PRNGs (Sander Vesik)
  Re: Breaking NCipher smartcard system (Paul Rubin)
  Re: Paradise shills?? (zapzing)
  Re: If you're in Australia, the government has the ability to modify your files. >> 
4.Dec.1999 (zapzing)
  old Microsoft Mail 3.0b encryption? (Keith A Monahan)
  Re: NSA should do a cryptoanalysis of AES (fungus)
  Frequency results of twofish and serpent. (albert)
  Re: Quantum Computers and Weather Forecasting (Joseph Bartlo)
  Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe    in a 
paper ... (Bruce Schneier)
  Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe    in a 
paper ... (David A Molnar)
  Re: How can you tell? (John)
  Re: NSA future role? ("Jeff Moser")
  Re: Frequency results of twofish and serpent. (Boaz Lopez)

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

From: Arthur Dardia <[EMAIL PROTECTED]>
Subject: PCI Cryto Card
Date: Tue, 07 Dec 1999 15:03:28 -0500

Great new product out for webmasters that need to improve SSL
performance for their e-stores, check it out:

http://isg.rainbow.com/products/cs_1.html

--
Arthur Dardia      Wayne Hills High School      [EMAIL PROTECTED]
 PGP 6.5.1 Public Key    http://www.webspan.net/~ahdiii/ahdiii.asc



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

From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Reply-To: [EMAIL PROTECTED]
Date: Tue, 7 Dec 1999 20:04:30 GMT

Johnny Bravo <[EMAIL PROTECTED]> wrote:
: On Tue, 7 Dec 1999 15:44:05 GMT, Tim Tyler <[EMAIL PROTECTED]> wrote:
:>Douglas A. Gwyn <[EMAIL PROTECTED]> wrote:
:>: Tim Tyler wrote:

:>:> You don't think 56-bits is a slightly small figure?  Even for its day?
:>
:>: It obviously wasn't.  DES far outlived its design life.
:>
:>Really?  For all either of us know DES may have been quietly being broken
:>in secret for very many years, behind closed doors.

:   Since we are playing the "what-if" game.  What if the NSA recovered
: a quantum computer from a UFO crash at Roswell New Mexico and has
: broken every code ever put into use since then?

...then possibly lots more codes will be broken than most people realise.

Your "if" hypothesises the existence of space-faring alien intelligences.

My "if" hypothesises the existence of a break in a fielded cypher that has
a relatively small keyspace, and has been in common use for many years.
-- 
__________
 |im |yler  The Mandala Centre  http://www.mandala.co.uk/  [EMAIL PROTECTED]

If at first you do succeed, try not to look astonished.

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

From: [EMAIL PROTECTED]
Subject: Breaking NCipher smartcard system
Date: Tue, 07 Dec 1999 20:22:53 GMT

nCipher have a smart card system which generates random keys and can
store them on a smart card.

Does anyone have any information/links onto any related weaknesses with
this particular system?

David Walker


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

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

From: Sander Vesik <[EMAIL PROTECTED]>
Subject: M-Box PRNGs
Date: 7 Dec 1999 20:54:43 GMT

First things first:
        * I have read the charter, but there are no newsgroups dedicated
          to (possibly strong) prngs
        * It may very well be the wheel re-invented
        * It probably *IS* snake-oil
        * It relies extensively on a not so widely analysed shiffer mode
        * There is no proof that it works, and I am not claiming so

Take it "just as thoughts". But here it comes:

***********************************************************************

Below are some thoughts on a PRNG (family of PRNGs) that should have the
following propeties:
        1) It requires relatively small amount of inital unknown true
           random state
        2) Requires modest amount of retained stae
        3) Knowing a single value from anywhere in the keystream should
           give absolutely the most minimal information about preceding
           and succeeding values
        4) Is secure enough for use in key-generating black boxes

The following assumes:
        a) cracking a block shiffer in CFNLF mode is *hard*.
        b) CFNLF mode is not overly easy to crack with a known plaintext
           attack, especially if only a part of the shiffertext is known
           (otherwise the required inital random state expands a lot)
        c) The work/benefit ration makes sense. For some chiffers, the
           effort required for key schedule is extensive.

=======================================

M-Box Pseudo-Random Nunmber Generators

======= ======== ========

M-Box is a construct consisting of:
        a) matrix A, consisting of n x n bits
        b) m-bit quantity K1
        c) m-bit quantity K2
        d) function f(d,K)

In the following, A[i] denotes the i-th row of matrix A.

Function R(t,M) is an operation that given a quantity t (ranging from 1 to
n) and an M-Box M does the following:
        1) for j=1..n
                K2=f(K1,K2)
                A[j]=f(A[j], K2)
        2) q=A[t]
        3) A=transpose(A)
        4) return(q)

======= ======== ========

The row selector t.

Initally, I would suggest a t of {n, n-1, n-2, ..., 2, 1, n, ...} leaving
at least n rotations of K2 between two consequitive values.

======= ======== ========

If f(d,K) is a block shiffer, then an M-Box is just an application of the
block shiffer in CFNLF mode on a set of data + some data shuffling, with
selective data output.

The quality/security of the M-Box without step 3, the transpose.

        1) Let's consider a case where the only unknown quantity to the
           adversary is K1. The adversary knows: K2, the inital state of
           A, and the sequence of values of t. Hence, the adversary knows:
           the start of the sequence of K2-s and which chiffertexts of the
           chiffertext octets he is going to see.

           In such a case, "breaking" the M-Box means breaking the block
           shiffer f in CFNLF mode in the case of a known reapeating
           plaintext: p0p1p2...pnp0p1p2... with a known inital K2, with
           the restriction that only one in every n chiffertext blocks is
           seen. *IF* also t0 == 1, K1 can be recovered easily (just two
           rounds through the machine matching a (plaintext, chiffertext)
           pair to a key), and the M-Box is broken. If t0 > 1, t0
           encryptions must be undone before the M-Box is compromised.

        2) Let's consider a case where the only unknown to the adversary
           quantities are K1 & K2.  That is, the adversary knowns: the inital
           state of the matrix A and the function used to generate t.

           In such a case, "breaking" the M-Box means breaking the block
           shiffer f in CFNLF mode in case of a known repeating plaintext:
           p0p1p2...pnp0p1p2.. with the restriction that of every
           n consecutive chiffertext bloks, he sees only one (but he knows
           which).

======= ======== ========

The transpose step is for added data confusion - after the transpose the
output value is no longer in a row, but a column. The adversary now knows
every t-th bit in the words, but not any of the other bits. I have no
proof that this actually does strengthen the algorithm rather than weaken. 
In the worst case, it would require someone with the crack of the shiffer
in the CFNLF mode to reconsider the analysis, upon which he/she discovers
the problem to have become simpler.

======= ======== ========

Types of M-Box PRNGs.

1) a statewise minimal M-Box PRNG of Z M-Boxes has a common K1 or K2 for
all M-Boxes (but not both!). Required is (Z+1) * m bits of inital random
state. Compromising any bit of the inital state potentially gives
information about all data generated by the PRNG.

2) a simple M-Box PRNG of Z M-Boxes consists of Z interleaved M-Boxes,
each with their own K1 and K2. Required is 2 * Z * m bits of inital random
state. Compormising exactly t bits of information from the inital state
gives information about a maximum of t M-Boxes (t < Z). Compromising N
M-Boxes compromises only Z/N of the random stream (independence of the
interleaved M-Boxes).

Note: A M-Box PRNG consisting of just one M-Box is both simple and
minimal. 

3) A V,Z scheduled M-Box PRNG uses a simple M-Box PRNG of V M-Boxes to
compute the M-Box schedule of a simple M-Box of Z M-Boxes. Required inital
state is (2 * (V + Z)) * m bits. If the first PRNG is compromised, the
shiffer reverts to a simple M-Box PRNG of Z M-Boxes. 

4) A V,Z chained M-Box PRNG uses a simple M-Box PRNG of V M-Boxes as a as
the source of the stream K1[n] for a simple M-Box PRNG of Z M-Boxes. 
Required inital state is (2 * (V + Z)) * m bits of random state. It
requires more effort per random number generated, with the exact amount
depending on how often the K1 are changed. At worst requires twice the
effort than a simple shiffer. 



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

From: [EMAIL PROTECTED] (Paul Rubin)
Subject: Re: Breaking NCipher smartcard system
Date: 7 Dec 1999 21:01:58 GMT

In article <82jqam$qa4$[EMAIL PROTECTED]>,  <[EMAIL PROTECTED]> wrote:
>nCipher have a smart card system which generates random keys and can
>store them on a smart card.
>
>Does anyone have any information/links onto any related weaknesses with
>this particular system?

The NCipher stuff is FIPS 140-1 level 3 certified (NFast/CA).
I doubt if they did anything stupid in the design.
I'm using their stuff and it looks very well done to me.
There are some features that I wish they'd add, but these
are not security problems.  Do you know of any weaknesses?

It's possible that some or all of the FIPS test results
(the testing is done by an independent lab) are available
to the public.  You might check into this.  I haven't.

More info about FIPS 140-1 is at: 
  http://csrc.nist.gov/fips/fips1401.htm

If you find out anything interesting, please let me know!

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

From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: rec.gambling.poker
Subject: Re: Paradise shills??
Date: Tue, 07 Dec 1999 21:23:45 GMT

I think the most important word in that
post is "buy". Why bother buying more
hardware when with a few extra lines of
code you can have something that is just
as good?

ZZ


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

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

From: zapzing <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: If you're in Australia, the government has the ability to modify your 
files. >> 4.Dec.1999
Date: Tue, 07 Dec 1999 21:54:32 GMT

It sound like they just want to cover
up evidence of tampering. Why not make
this impossible for them? If the computer
detects tampering, it does not _write_
something, it _erases_ it, and securely
by overwriting the space. Then noone
could cover up evidence of tampering, no
matter what legal "powers" they had.

ZZ


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

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

From: [EMAIL PROTECTED] (Keith A Monahan)
Subject: old Microsoft Mail 3.0b encryption?
Date: 7 Dec 1999 22:08:57 GMT

I'm looking to write a small program that converts microsoft
mail files over to regular text files.  I've briefly looked
over the data file it puts out and it appears encrypted.
There does seem to be some form to the file and it may just
turn out to be some simple XOR cipher.  Since I'm sure
Microsoft didn't release the file format or encryption method
AFAIK, I'm hoping someone wrote a little cracker where I could
steal the algorithm/format from.  The generation of products
developed around the same time by Microsoft have all been long
broken.(ie MS-Word, MS-Access,)

I've looked on the popular key recovery sites around including
Joe's.  I very well may have missed it, though.

The funny part is that I have the key, but the mail program does
not allow you to export (in plaintext) the messages.  We're
dealing with an inordinate amount of messages here - so cut/paste,
remailing, etc won't cut it.

TIA,

Keith



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

From: fungus <[EMAIL PROTECTED]>
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Tue, 07 Dec 1999 16:11:44 +0100



"Douglas A. Gwyn" wrote:
> 
> Tim Tyler wrote:
> > You don't think 56-bits is a slightly small figure?  Even for its day?
> 
> It obviously wasn't.  DES far outlived its design life.

>From who's viewpoint? From Joe Public's or the NSA's?


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


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

From: albert <[EMAIL PROTECTED]>
Subject: Frequency results of twofish and serpent.
Date: Tue, 07 Dec 1999 22:58:38 GMT

I took an encryption of some text with twofish and serpent (straight
ECB).  I then did a frequency count of the results.  I'm shocked (well,
not really) on how evenly distributed the values are.  Here are my
results:  Based on encryption of a few random text files that are about
200K in size.  No, this is not the most scientific of test methods, not
claiming it is, just some info to pass along...  Good to note that the
standard deviation is very low; with highs being 6.20% and lows being
5.90% on both algorithms (rounded).

Albert.

Serpent:
Character Percentage
5 6.2%
1 6.1%
3 6.1%
0 6.1%
2 6.1%
A 6.1%
D 6.1%
B 6.1%
7 6.1%
6 6.0%
9 6.0%
F 6.0%
C 6.0%
E 6.0%
4 6.0%
8 5.9%



Twofish:
Character Percentage
4 6.2%
D 6.2%
C 6.1%
A 6.1%
2 6.1%
F 6.1%
0 6.1%
7 6.1%
B 6.1%
8 6.1%
1 6.0%
6 6.0%
5 6.0%
3 6.0%
9 6.0%
E 5.9%



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

From: Joseph Bartlo <[EMAIL PROTECTED]>
Crossposted-To: sci.physics,sci.geo.meteorology
Subject: Re: Quantum Computers and Weather Forecasting
Date: Tue, 07 Dec 1999 19:06:07 -0500

This is a multi-part message in MIME format.
==============613E8A33D36596EEFE4DEFB2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

 
==============613E8A33D36596EEFE4DEFB2
Content-Type: text/html; charset=us-ascii; name="color.htm"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="color.htm"
Content-Base: "file:///C|/WINDOWS/Desktop/color.htm"

<HTML>
<BODY BGCOLOR=#FFFFFF LINK=#FF0080>
<FONT FACE="Book Antiqua">
<FONT COLOR=#000000>
Trevor Jackson, III wrote:
<P>> In "The Demolished Man" Bester uses symbols as letters in proper names.
> There's a Mr. S&ers, Mr. @kins, etc.</FONT>
<FONT COLOR=#960000>
<P>Why stop there ?  Use <FONT COLOR=#0000FF>c</FONT><FONT COLOR=#FF8000>o</FONT><FONT 
COLOR=#00FF00>l</FONT><FONT COLOR=#8000FF>o</FONT><FONT COLOR=#FF0080>r</FONT><FONT 
COLOR=#960000> also.  An entire language exists including ridiculous words such as 
</FONT><FONT COLOR=#0000FF>some</FONT><FONT COLOR=#00FF00>what</FONT><FONT 
COLOR=#960000> (</FONT><FONT COLOR=#0000FF>some</FONT><FONT COLOR=#960000> - 
</FONT><FONT COLOR=#00FF00>what</FONT><FONT COLOR=#960000> ?), </FONT><FONT 
COLOR=#0080FF>where</FONT><FONT COLOR=#FF0080>as</FONT><FONT COLOR=#960000>,...
<P><A HREF=http://www.voicenet.com/~jbartlo>Joseph</A>
</FONT></FONT>
</BODY>
</HTML>
==============613E8A33D36596EEFE4DEFB2==


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

From: [EMAIL PROTECTED] (Bruce Schneier)
Crossposted-To: alt.privacy
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe  
  in a paper ...
Date: Wed, 08 Dec 1999 00:55:14 GMT

On Tue, 07 Dec 1999 20:08:05 GMT, amadeus @DELETE_THIS.netcomuk.co.uk
(Jim Dunnett) wrote:

>On Mon, 06 Dec 1999 16:32:21 -0500, [EMAIL PROTECTED] wrote:
>
>>Cell Phone Crypto Penetrated by Declan McCullagh 
>>
>>10:55 a.m. 6.Dec.1999 PST 
>>Israeli researchers have discovered design flaws that allow the descrambling of
>>supposedly private conversations carried by hundreds of millions of wireless
>>phones. 
>>
>>Alex Biryukov and Adi Shamir describe in a paper to be published this week how a
>>PC with 128 MB RAM and large hard drives can penetrate the security of a phone
>>call or data transmission in less than one second. 
>
>And listen to it in real-time? I think not.

Actually, the math of the attack implies that they can.  Or, at least,
there is no cryptographic reason why they cannot.

Bruce
**********************************************************************
Bruce Schneier, Counterpane Internet Security, Inc.  Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com

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

From: David A Molnar <[EMAIL PROTECTED]>
Crossposted-To: alt.privacy
Subject: Re: Cell Phone Crypto Penetrated >> 6.Dec.1999 >> Biryukov & Shamir describe  
  in a paper ...
Date: 8 Dec 1999 00:30:30 GMT

In sci.crypt Jim Dunnett <amadeus @DELETE_THIS.netcomuk.co.uk> wrote:
>>Alex Biryukov and Adi Shamir describe in a paper to be published this week how a
>>PC with 128 MB RAM and large hard drives can penetrate the security of a phone
>>call or data transmission in less than one second. 

> And listen to it in real-time? I think not.

Why do you think not?




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

From: John <[EMAIL PROTECTED]>
Subject: Re: How can you tell?
Date: Tue, 07 Dec 1999 17:06:01 -0800

Then maybe I should have asked how one would attack a crypto program?

http://www.aasp.net/~speechfb



In article <[EMAIL PROTECTED]>, Pelle Evensen <[EMAIL PROTECTED]>
wrote:
> John ([EMAIL PROTECTED]) wrote:
> > Say you had an encrypter and no source.  How would you go about
> > verifying it?  I usually do extensive tests on the cryptext.  Is
> > getting chi-square statistics on it good? If so, how many times
> and at
> > what intervals would give best results?
> Marsaglia has written some great papers about tests for "random"
> sequences.
> The website hasn't been updated in quite a while but the stuff on
> the CD
> is nice.
> http://stat.fsu.edu/~geo/diehard.html
> http://stat.fsu.edu/pub/diehard/cdrom
> To write a "stream cipher" that will pass all known tests for
> randomness;
> 1. Take a statistically good PRNG, KISS, or a MWC generator or
> whatever you
>    like that passes all statistical tests known to you. Call it r,
> r[n]
>    is the nth number from the generator. Seed r with a small seed
> based
>    on k (the key), just make sure that the initial seed is big
> enough to be
>    hard to deduce (or make collide) from testing many k's but
> still small
>    enough to trivially brute force.
> 2. Take c[n] = r[n] + e(k, p[n]). Even if the "encryption
> function" e(k, x) is
>    something like e(k, p[n]) = k ^ p[n], that is simply the
> plaintext xored
>    with the key, the output will look "random".
>    (c[n] = nth ciphertext block, e(k, x) = the encryption of x
> under key k,
>     p[n] = nth plaintext block.)
> Moral: You can't get any information whatsoever about a
> cryptosystems security
> from statistically measuring the output data. This also works the
> other way
> round, you could of course add redundant data to a secure
> algorithm's output
> to make the data fail any such tests. Not that I know why anyone
> would do
> that but it illustrates "no information whatsoever". :-)
> Cheers,
>   Pell
> --
> Pelle Evensen, [EMAIL PROTECTED]                   Telenordia
> AB/Algonet
> http://www.evensen.org/pgp.html for public key.
> PGP fingerprint      22 DC 52 0D 7E 00 F7 9C  8B EB F0 55 1E 8C 71
> 5E



* 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: "Jeff Moser" <[EMAIL PROTECTED]>
Crossposted-To: alt.politics.org.nsa
Subject: Re: NSA future role?
Date: Tue, 7 Dec 1999 20:37:47 -0500

> Accountability.  Profit.  NASA has lost about $2Billion thus far on Mars
stuff.  Any of
> them fired?  No.  If it was the private sector, performance and reward are
linked, not
> so in the public sector.

Wasn't it Lockheed Martin that was in on the units error? I thought they
co-designed it.





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

From: Boaz Lopez <[EMAIL PROTECTED]>
Subject: Re: Frequency results of twofish and serpent.
Date: Tue, 07 Dec 1999 17:42:52 -1000

albert wrote:
> 
> I took an encryption of some text with twofish and serpent (straight
> ECB).  I then did a frequency count of the results.  I'm shocked (well,
> not really) on how evenly distributed the values are.  Here are my
> results:  Based on encryption of a few random text files that are about
> 200K in size.  No, this is not the most scientific of test methods, not
> claiming it is, just some info to pass along...  Good to note that the
> standard deviation is very low; with highs being 6.20% and lows being
> 5.90% on both algorithms (rounded).
> 
> Albert.
> 
> Serpent:
> Character Percentage
> 5 6.2%
> 1 6.1%
> 3 6.1%

Good work. If you do some more work, 
you could do the same analysis on one round, 
two rounds...

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


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