Cryptography-Digest Digest #595

[Digestifier]

Cryptography-Digest Digest #595, Volume #10  Sat, 20 Nov 99 01:13:06 EST

Contents:
  Re: A Random Key Cipher Machine (Mark Adkins)
  Re: A Random Key Cipher Machine (Mark Adkins)
  Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
  Re: AES cyphers leak information like sieves (Tom St Denis)
  Re: AES cyphers leak information like sieves (Jerry Coffin)
  Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
  Arithmetica Inc Website (was GT-1 Consortium) (MikeAt1140)



Date: Fri, 19 Nov 1999 20:41:57 -0500 (EST)
From: Mark Adkins <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine

Tom St Denis <[EMAIL PROTECTED]> wrote:
   
> Typing for the most part is too regular to use as 'random' sampling
> points along a smooth sine wave.  You would be sampling at common
> points during 'typing bursts'.
>   
>   Neat idea otherwise.
>   
>   Tom


I don't think so.  Even the most "regular" typing only *seems*
regular, and even then only because the standards used by the
perceiver are coarse and inadequate.  As I said before, if the
frequency of the sine wave is sufficiently fast (and this need
not be that fast even with respect to the fastest human typist)
no two consecutive keystrokes will fall within the same sample
sector, or even consecutive sample sectors, and even the smallest
irregularities (which always exist) will be randomized.

Look at it this way: a sine wave is mathematically equivalent
to a radius sweeping the circumference of a circle at constant
speed.  If you divide the circle into sectors the sweep spends
the same amount of time in each sector (the exact time depending
upon the speed of the sweep).  The circle is divided into 26
sectors, each of which corresponds to a different digital code
and hence also to a different key letter through the 
programmable translation table.  Which sector is selected
depends upon which sector the radius sweep is in at the time
a plaintext key is pressed.  

Now, it's obvious that if the sweep is fast enough, no two
consecutively typed keys will select the same sector, or
for that matter two consecutive sectors.  Furthermore, only 
if the typed keys were separated by *exactly* identical 
temporal intervals would the sweep select sectors separated 
even by a constant distance.  Even the most regular human 
typing during "typing bursts" is not separated by identical 
temporal intervals.  The variations in the temporal intervals
between keys may be small or non-existent by the human 
standard of someone using their ears to listen, but
the smallness of these variations in the present case is 
a function of the speed of sampling.  If the sweep is 
sufficiently fast then these "small" variations in the temporal
interval between typed keys become *large* variations because 
the sampling mesh (so to speak) is much finer.  The 
irregularities become *magnified* by the high frequency of 
the sweep.  

The nice thing about this is that the sweep is out of synch
with the typing and *stays* out of synch with the typing,
because the sweep is always regular but the typing is always
irregular if the frequency of the sine wave generator is
sufficiently fast.  This is what provides the randomization 
effect.  Even if some irregularity (within specified tolerances)
exists in the frequency of the sine wave generator, this
irregularity does not match the irregularity in typing or
permit a synch.


--
Posted for my own amusement, since you are all figments.

Mark Adkins ([EMAIL PROTECTED])



--

Date: Fri, 19 Nov 1999 21:15:07 -0500 (EST)
From: Mark Adkins <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine

A couple of additional points.

The fact that the digital codes corresponding to key letters are
transmitted with the ciphertext is of no value to the unauthorized
receiver, since from his perspective each digital code could
represent any of the 26 key letters, and without the translation
table (which is programmable) he has no idea which one.  Thus,
to the unauthorized receiver, no more information is present
than if the ciphertext alone were received.  Since the key
letters are random, the digital codes corresponding to them
are also random (as are the ciphertext letters produced from
the random key letters).  Frequency analysis is therefore 
useless.

Thus, the possibility of a variable weaving scheme (for the 
weaving of the digital codes into the ciphertext in the 
transmitted signal) is merely an extra layer of security,
and really superfluous.  But note that if the ciphertext
letters are digitally encoded for transmission, then all
the unauthorized receiver will see is one big stream of
numbers, and will have no idea how to unweave these even
if he knew that unweaving was necessary.  (Not that it
would do him any good even if he did know the correct
unweaving scheme for that message!)

Finally

Cryptography-Digest Digest #594

[Digestifier]

Cryptography-Digest Digest #594, Volume #10  Fri, 19 Nov 99 22:13:03 EST

Contents:
  Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
  Re: Modified DH - ok? ([EMAIL PROTECTED])
  Re: AES cyphers leak information like sieves (wtshaw)
  Is this "legal"???  Export concept presented (albert)
  Re: AES cyphers leak information like sieves (Tim Tyler)
  Re: AES cyphers leak information like sieves (Tim Tyler)
  Re: AES cyphers leak information like sieves (Tim Tyler)
  Re: AES cyphers leak information like sieves (Tim Tyler)
  Re: Simpson's Paradox and Quantum Entanglement (Andy Spragg)
  Re: AES cyphers leak information like sieves (Jerry Coffin)
  Re: Distribution of intelligence in the crypto field (albert)
  Re: Simpson's Paradox and Quantum Entanglement ("karl malbrain")
  Re: GT-1 Consortium (David A Molnar)
  Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)



From: [EMAIL PROTECTED] (Johnny Bravo)
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 17:36:16 GMT

On Fri, 19 Nov 1999 15:23:02 GMT, [EMAIL PROTECTED]
(SCOTT19U.ZIP_GUY) wrote:

>  You asshole he messed his math up and admitted it so shut the fuck up.

  His math was correct, he stated that 28 wheels with 26 positions
each had more than 2^128 states.  The fact that you still can't figure
it out speaks volumes for your mathematical ability.

>The argument really is over wheather one just considers the starting postions
>of 3 or more fixed wheels as the key. Or if the actuall order of the 
>characters on the wheels should count as part of the key. I prefer to count 
>the wheel types possible it seems you and tom only want to use fixed wheels.

  That's because the Enigma did use fixed wheels, we were talking
about what the Enigma actually was, not a hypothetical system that
never existed.  

>Which greatly reduce the key space. But face it one is simulating the engima
>the order of characters on the wheels would be part of the key space.

  Since the order of characters on the wheels is fixed and cannot be
changed by the users, then you are not simulating the Enigma if you
allow the users to change the wiring on the wheels.  If you do, you
are no longer talking about Enigma, but some hypothetical variant that
was never used.

  Johnny Bravo


--

From: [EMAIL PROTECTED]
Subject: Re: Modified DH - ok?
Date: Fri, 19 Nov 1999 22:42:46 GMT

[EMAIL PROTECTED] wrote:

> May i propose a change:
>
> PtoQ <-- (P + (P * N)) mod M
> QtoP <-- (Q + (Q * N)) mod M

That's the same as your first scheme, exept you're
using (N+1) in plance of N.

> With this, i (errare humanum est) am unable to calculate P from Mr
> Shimizu's
> recommendation.

Since you replaced N by N+1 in the scheme, do the
same in the attack.

[...]
> (P.S: Sorry for continuing on with this, but probably more people than
> me
> need this kind of thing so it can be implemented in on low end
> languages.

I expect you would enjoy more success in learning
to implement large-integer modular exponentiation
in a low-level programming language than you'll
have in inventing a new public-key cipher.  The
latter seems to be several million times harder
than the former.

--Bryan


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

--

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 17:07:05 -0600

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

> wtshaw <[EMAIL PROTECTED]> wrote:

> 
> : Where length is flexable, only the last block might be short.
> 
> Where length is completely flexible, there's no need for any block
> to be short.

I meant short as in the last block might be shorter than the others, not
incomplete.
> 
> I understand that not everyone thinks that the technical problems with
> variable length blocks have been resolved, and not everyone agrees that
> larger block sizes are better today.  However - in principle - larger
> blocks (not necessarily with accompanying larger keys) seem to me to be a
> good idea.

Having the ability for huge blocks cuts the overhead in the GVA.  With
overshuffled ciphers, this would be a killer, but I have no problems with
blocks over 1000 bits.  The bigger the blocks can be, the fewer of them
that are needed.
-- 
A site of interest: www.echelonwatch.org

--

From: albert <[EMAIL PROTECTED]>
Subject: Is this "legal"???  Export concept presented
Date: Fri, 19 Nov 1999 14:48:42 -0800

Algorithms such as RC6 are parameterized.
40bit crypto algorithms are exportable.

So what if I export code that is RC6 as 32 bit key, 32 bit block, and 1
round?  Would it them be considered exportable???  Since it's
parameterized, then I can email it to someone, and they can in turn
change it to 128bits.

I think crypto poli

Cryptography-Digest Digest #922

[Digestifier]

Cryptography-Digest Digest #922, Volume #8   Sun, 17 Jan 99 17:13:07 EST

Contents:
  Re: Twofish vs DES? (William Hugh Murray)
  Re: Practical True Random Number Generator (R. Knauer)
  Re: Trying to find simple, yet effective implementation of crypto... ("Ryan 
Phillips")
  Re: Trying to find simple, yet effective implementation of crypto... (wtshaw)
  Re: mars-algorythm ("Markus Hahn")
  Re: Trying to find simple, yet effective implementation of crypto... (Mr. Tines)
  Re: Too simple to be safe (David Wagner)
  Re: file size of encrypted vs. unencrypted data (Bill Unruh)
  Re: Rabin/Williams/Koyama .. and Flannery? (David A Molnar)
  Re: Question on current status of some block ciphers in AC2 (David Hamilton)
  Re: file size of encrypted vs. unencrypted data ([EMAIL PROTECTED])
  Java speed vs 'C' (was Re: New Twofish Source Code Available) (Mr. Tines)



From: William Hugh Murray <[EMAIL PROTECTED]>
Subject: Re: Twofish vs DES?
Date: Sun, 17 Jan 1999 14:20:46 -0500

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

Consider also that we have two decades worth of research that says the
cheapest known (cryptanalytic) attack against DES is an exhaustive
attack against the key while Twofish has only been in existence for
months.  

Consider that the ratio of work for doing a DES encryption with the key
to that of recovering a message (by cryptanalysis) without benefit of
the key is 1 to 2^55.  That is what it was in 1975 and that is what it
is today.  

Consider also that the standard to replace DES, FIPS-46-3 was announced
last month and it is Triple-DES.  

Consider that anyone of us can write an encryption algorithm which we
cannot break.  The work is not in writing it but in knowing anything
about it.  For a long time to come we will know more about the DES than
we know about any other algorithm.

Consider that I can now do a Triple DES operation for 2.5 x 10^-4 what a
DES operation cost when DES was announced.  

Consider that in some senses the assumptions that underly DES are now
obsolete.  These include the fact that both computing power and storage
are scarce.  Thus, the balance between complexity and key-length that
was struck in 1975 cannot be the right choice for today except by
accident.

Consider that NSA is right when they say that a single standard
algorithm reduces the work of an attacker, that most modern encryption
implemntations support an arbitrary number of algorithms and leave the
choice to message or session-negotiation time.  

Consider that if 56 bit DES is the weak link in your security, you are
probably the most secure person in the world.  If encryption is the weak
link in your security, you are stupid.  

Consider that, for most of us, bribery is more efficient than
cryptanalysis; nation states prefer breaking fingers to breaking codes.

In a few hours I leave for the RSA conference.  At an earlier such
conference Arjen Lenstra said, "The algortihms (the context was DES and
RSA) are timeless; what matters now is how we use them."  At the same
conference Paul Kocher said, "Think dollars, not bits."  

In short, there are a lot of considerations and few shortcuts.

Matt Curtin wrote:
> 
> "TERACytE" <[EMAIL PROTECTED]> writes:
> 
> > Which is better?  Twofish or DES?
> 
> Consider that Twofish is being considered for AES, the standard to
> replace DES...
> 
> --
> Matt Curtin [EMAIL PROTECTED] http://www.interhack.net/people/cmcurtin/
==F133729FE6831C91C864107B
Content-Type: text/x-vcard; charset=us-ascii;
 name="whmurray.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for William Hugh Murray
Content-Disposition: attachment;
 filename="whmurray.vcf"

begin:vcard 
n:Murray;William Hugh
tel;fax:800-690-7952
tel;home:203-966-4769
tel;work:203-761-3088
x-mozilla-html:FALSE
org:Deloitte   Touche
adr:;;24 East Avenue, Suite 1362;New Canaan;Connecticut;06840;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Executive Consultant, Information Security
x-mozilla-cpt:;-1
fn:William Hugh Murray
end:vcard

==F133729FE6831C91C864107B==


--

From: [EMAIL PROTECTED] (R. Knauer)
Subject: Re: Practical True Random Number Generator
Date: Wed, 13 Jan 1999 13:54:29 GMT
Reply-To: [EMAIL PROTECTED]

On Wed, 13 Jan 1999 14:06:13 +0100, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote:

>Since I am not physicist, I have to pose stupid questions.

Why would you say that? It is very easy sometimes for
non-practitioners to ask brilliant questions that practitioners would
never think of because they are prejudiced. All forward movement in
science comes about someone questions the status quo, and that is
usually done by people who have not snuggled down comfortably in the
middle of the herd.

>For the commonly employed radioactive materials, at times they are
>

Cryptography-Digest Digest #593

[Digestifier]

Cryptography-Digest Digest #593, Volume #10  Fri, 19 Nov 99 19:13:03 EST

Contents:
  Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
  Re: AES cyphers leak information like sieves (wtshaw)
  Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
  Re: Modified DH - ok? (Bob Silverman)
  Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
  Re: Group English 1-1 all file compressor (SCOTT19U.ZIP_GUY)
  Re: technical writing skills required! (Tom St Denis)
  Re: S/MIME plug-in for Eudora? Strong Encryption (Miguel Cruz)
  Do flight data recorders use encryption? (albert)
  Re: Ultimate Crypto Protection? (albert)
  Distribution of intelligence in the crypto field (albert)
  Re: Letter Frequency in English Texts vs. Name Lists (albert)
  Re: AES cyphers leak information like sieves ("Rick Braddam")
  bits of diffiehellman private key (Tom St Denis)
  Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)



From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 19:29:35 GMT

PLEASE promptly ignore my post.  I can't think straight this week.

Thanks.  I am going into passive mode now ... arrg... the minds a-
wasting.

Thanks,
Tom

In article <8147gk$3t8$[EMAIL PROTECTED]>,
  Tom St Denis <[EMAIL PROTECTED]> wrote:
> In article <813mg8$1ipk$[EMAIL PROTECTED]>,
>   [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> >   You asshole he messed his math up and admitted it so shut the fuck
> up.
> > The argument really is over wheather one just considers the starting
> postions
> > of 3 or more fixed wheels as the key. Or if the actuall order of the
> > characters on the wheels should count as part of the key. I prefer
to
> count
> > the wheel types possible it seems you and tom only want to use fixed
> wheels.
> > Which greatly reduce the key space. But face it one is simulating
the
> engima
> > the order of characters on the wheels would be part of the key
space.
>
> Technically you are closer to being right Mr Scott.  There are two
ways
> to view the rotor.
>
> 1) As a random permutation of A..Z or 0..25, which of course is more
> historically accurate.  In this case a x-rotor system has a keyspace
of
> log2(x!(26!)).  This of course matches a 125-bit key in keyspace with
> only 14 [or so] rotors. [125 bits is closer to the keyspace then 128
> bits is ...]
>
> 2) As a fixed permutation [26 permutations in all] where the order is
> random.  This is not historically accurate.  In this case a x-rotor
> system has a keyspace of log2(26^x).
>
> Let's not beat this one into the ground.  I was looking at the rotors
> as in #2.  I used the wrong model.  Sorry.  Done deal.
>
> My point however is that rotors were not broken in WWII via brute
> force.  Also the five-rotor systems have a 'key' of log2(5! x 26!) or
> about 96 bits, which is not even close to 128 bits.
>
> Tom
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


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

--

From: [EMAIL PROTECTED] (wtshaw)
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 14:14:15 -0600

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

> wtshaw <[EMAIL PROTECTED]> wrote:
> : In article <[EMAIL PROTECTED]>, "Douglas A. Gwyn"
<[EMAIL PROTECTED]> wrote:
> : ...
> 
> : So many have worked so hard to define as respectable those ciphers which
> : do not provide error recovery within themselves, while down playing those
> : that might.  The discussion highlights that normal respectable designs
> : are, in essence, insufficent in themselves.
> 
> : It does me good to see so many beginning to define vital problems, even as
> : I have already solved them.  And, if my solutions have fallen on deaf ears
> : because they sound strange, better start giving a listen, as they are
> : sound answers to the types of difficulties under discussion.
> 
> I /presume/ you refer to The Grandview Algorithm - as described at:
> http://radiofreetexas.com/wts/gva.htm

> 
> After looking at this, I observe that it /appears/ to have the same
> characteristic that is being criticised here, that there's almost a 1-1
> relationship between between the cyphertext and the plaintext.
> 
> I've only given the system a cursory look, but it /appears/ to me that
> the consequences of an error in a single letter will /usually/ affect
> three adjacent letters in the plaintext (and there's a small chance that
> they will destroy the message totally?).

Only if the error is in the first few letters of a block are the results
traumatic. Otherwise, each error is seen as a single character typo.
> 
> Information /appears/ to propagate horizontally through the message
> in only one direction, and by at most two characters.

The propagation is setable.  I commonly use nine.  Small propa

Cryptography-Digest Digest #921

[Digestifier]

Cryptography-Digest Digest #921, Volume #8   Sun, 17 Jan 99 14:13:03 EST

Contents:
  mars-algorythm ("Fredi Suter")



From: "Fredi Suter" <[EMAIL PROTECTED]>
Subject: mars-algorythm
Date: Sun, 17 Jan 1999 17:59:40 +0100

does anyone have the "std_defs.h" - file, needed to compile the
mars-algorythm?

email me:  [EMAIL PROTECTED]




begin 666 mars3.c
M#0HO*B!4:&ES(&ES(&%N(&EN9&5P96YD96YT(&EM<&QE;65N=&%T:6]N(&]F
M('1H92!-05)3(&5N8W)Y<'1I;VX@(" @("HO#0HO*B!A;&=O2!G:79E
M('!E2 Q.3DX(" @("HO#0HO*B @(" @(" @(" @(" @(" @(" @(" @
M(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @(" @("HO
M#0H-"B-I;F-L=61E("(N+B]S=&1?9&5FPT*(" @(#!X,#ED,&,T-SDL(#!X,CAC.&9F93 L(#!X.#1A
M839C,SDL(#!X.61A9#&8Q-#DP,F4R+" P>#-E.3@Q930R+" P>#AB9C4S96(V+" P>#=F-&)F.&%C
M+" -"B @(" P>#@S-C,Q9C@S+" P>#(U.3##-A-SDS,60T+" -"B @(" P>#1F.#0V-#4P+" P>#5C-C1C,V8V+" P>#(Q
M,&$U9C$X+" P>&,V.3@V83(V+" -"B @(" P>#(X9C1E.#(V+" P>#-A-C!A
M.#%C+" P>&0S-#!A-C8T+" P>#=E83@R,&,T+" O*B P># R," @(" J+PT*
M(" @(#!X-3(V-C@W8S4L(#!X-V5D9&0Q,F(L(#!X,S)A,3%D,60L(#!X.6,Y
M968P.#8L( T*(" @(#!X.#!F-F4X,S$L(#!X86(V9C T860L(#!X-39F8CEB
M-3,L(#!X.&(R93 Y-6,L( T*(" @(#!X8C8X-34V864L(#!X9#(R-3!B,&0L
M(#!X,CDT83&5A9F,X8V$X+" P>&1B,3$R.60V+" P>&(P-#0Y
M93(P+" P>#!F-30P-V9B+" -"B @(" P>#8Q-C=D.6$X+" P>&0Q9C0U-S8S
M+" P>#1D86$Y-F,S+" P>#-B96,U.34X+" -"B @(" P>&%B86)A,#$T+" P
M>&(V8V-D,C Q+" P>#,X9#8R-SEF+" P># R-C@R,C$U+" -"B @(" P>#AF
M,S# Y,F,R,S=E+" P>&)F8S4V-3DS+" P>#,R.#@Y9#)C+" O
M*B P># U," @(" J+PT*(" @(#!X.#4T8C-E.34L(#!X,#5B8CEB-#,L(#!X
M-V1C9#5D8V0L(#!X83 R93DR-F,L( T*(" @(#!X9F%E-3(W934L(#!X,S9A
M,6,S,S L(#!X,S0Q,F4Q864L(#!X9C(U-V8T-C(L( T*(" @(#!X,V,T9C%D
M-S$L(#!X,S!A,F4X,#DL(#!X-CAE-68U-3$L(#!X.6,V,6)A-#0L( T*(" @
M(#!X-61E9#!A8C@L(#!X-S5C93 Y8S@L(#!X.38U-&8Y,V4L(#!X-CDX8S!C
M8V$L("\J(#!X,#8P(" @("HO#0H@(" @,'@R-#-C8C-E-"P@,'@R8C V,F(Y
M-RP@,'@P9C-B.&0Y92P@,'@P,&4P-3!D9BP@#0H@(" @,'AF8S5D-C$V-BP@
M,'AE,S5F.3(X."P@,'AC,#&-F,V(X-S!F
M+" P>&(T,30Y,S5C+" P>#8V-#0V-65D+" P># R-&%C86,W+" -"B @(" P
M>#4Y83#%D,CDS-F$W+" P>&1C-3@P86$V+" P>&-F-3# T,&$W83$P+" P>#9C9#@Q.# W+" P>#AA.3AB931C+" P
M>&%C8V5A,#8S+" -"B @(" P>&,S,V4Y,F(U+" P>&0Q93!E,#-D+" P>&(S
M,C(U,3=E+" P>#(P.3)B9#$S+" O*B P># Y," @(" J+PT*(" @(#!X,S@V
M8C)C-&$L(#!X-3)E.&1D-3@L(#!X-3@V-39D9F(L(#!X-3 X,C S-S$L( T*
M(" @(#!X-#$X,3$X.38L(#!X93,S-V5F-V4L(#!X9#,Y9F(Q,3DL(#!X8SDW
M9C!D9C8L( T*(" @(#!X-CAF96$P,6(L(#!X83$U,&$V934L(#!X-34R-3@Y
M-C(L(#!X96(V9F8T,6(L( T*(" @(#!X9#=C.6-D-V$L(#!X838Q.6-D.64L
M(#!X8F-F,#DU-S8L(#!X,C8W,F,P-S,L("\J(#!X,&$P(" @("HO#0H@(" @
M,'AF,# S9F(S8RP@,'@T86(W834P8BP@,'@Q-#@T,3(V82P@,'@T.#=B83EB
M,2P@#0H@(" @,'AA-C1F8SEC-BP@,'AF-CDU-V0T.2P@,'@S.&(P-F$W-2P@
M,'AD9#@P-69C9"P@#0H@(" @,'@V,V0P.31C9BP@,'AF-3%C.3DY92P@,'@Q
M86$T9#,T,RP@,'AB.#0Y-3(Y-"P@#0H@(" @,'AC93EF.&4Y.2P@,'AB9F9C
M9##=B,C%B93,S+" P>#,Y-V8T,6)D+" P>#1E.31D,3,Q+" P>#DR
M8V,Q9CDX+" -"B @(" P>#4Y,35E834Q+" P>#DY9C@V,6(W+" P>&,Y.3@P
M83@X+" P>#%D-S1F9#5F+" -"B @(" P>&(P830Y-68X+" P>#8Q-&1E960P
M+" P>&(U-S#4Y-#$W.3)D+" -"B @(" P>&9A.3!C,68X+" P
M>#,S9C@R-&(T+" P>&,T.38U,S#-F9C9D-34P+" O*B P>#!C," @
M(" J+PT*(" @(#!X-&-A-69E8S L(#!X.#8S,&4Y-C0L(#!X-6(S9F)B9#8L
M(#!X-V1A,C9A-#@L#0H@(" @,'AB,C S,C,Q82P@,'@P-#(Y-S4Q-"P@,'@R
M9#8S.3,P-BP@,'@R96(Q,S$T.2P@#0H@(" @,'@Q-F$T-3(W,BP@,'@U,S(T
M-3EA,"P@,'@X935F-#@W,BP@,'AF.38V8S=D.2P@#0H@(" @,'@P-S$R.&1C
M,"P@,'@P9#0T9&(V,BP@,'AA9F,X9#4R9"P@,'@P-C,Q-C$S,2P@+RH@,'@P
M9# @(" @*B\@#0H@(" @,'AD.#,X93=C92P@,'@Q8F,T,60P,"P@,'@S83)E
M.&,P9BP@,'AE83@S.#,W92P-"B @(" P>&(Y.#0W,S=D+" P>#$S8F$T.#DQ
M+" P>&,T9CAB.30Y+" P>&$V9#9A8V(S+" -"B @(" P>&$R,35C9&-E+" P
M>#@S-3DX,SAB+" P>#9B9#%A83,Q+" P>&8U-SED9#4R+" -"B @(" P>#(Q
M8CDS9CDS+" P>&8U,3#$X-V1F9&1E+" P>&4Y-&%E8C#!E," @(" J+R -"B @(" P>#)B,SAF9#4T+" P>#0S,61E,61A+" P
M>&%B,SDT.#(U+" P>#EA9#,P-#AF+ T*(" @(#!X9&9E83,R86$L(#!X-C4Y
M-##9B-3=E,S4T+" P>&%D.3$S8V8W+" P>#=E,38V.#AD+" P
M>#4X.##$P," @(" J+PT*(" @(#!X,F,R9F,W9&8L(#!X
M93,X.6-C8S8L(#!X,S W,SAD9C$L(#!X,#@R-&$W,S0L( T*(" @(#!X93$W
M.3=A.&(L(#!X831A.&0U-V(L(#!X-6(U9#$Y,V(L(#!X8SAA.#,P.6(L( T*
M(" @(#!X-S-F.6$Y-S@L(#!X-S,S.3AD,S(L(#!X,&8U.34W,V4L(#!X93ED
M9C)B,#,L( T*(" @(#!X93AA-6(V8S@L(#!X.#0X9# W,#0L(#!X.3AD9CDS
M8S(L(#!X-S(P83%D8S,L("\J(#!X,3$P(" @("HO( T*(" @(#!X-C@T9C(U
M.6$L(#!X.30S8F$X-#@L(#!X838S-S Q-3(L(#!X.#8S8C5E83,L( T*(" @
M(#!X9#$W8CDW.&(L(#!X-F0Y8C4X968L(#!X,&$W,#!D9#0L(#!X83#(S8F5C8C8T+" P>&$P-S5F,V$S+" P># X.&8X96%D+" P># W861F
M,34X+" -"B @(" P>#&9A8V%B9C-D+" P>&,P.3&8W-C&1A-#1E.65D+" P>#)C.#4T8S$R+" P
M>#,U.3,U9F$S+" P>#)F,#4W9#EF+" -"B @(" P>#8Y,#8R-&8X+" P>#%C
M8C!B869D+" P>#=B,&1B9&,V+" P>#@Q,&8R,V)B+" O*B P>#$T," @(" J
M+PT*(" @(#!X9F$Y,CEA,6$L(#!X-F0Y-CEA,3#$V,&)E860W+" P>#5D-#DT-C4V+" P>#,U
M9CAA-S1B+" P>#%E-&4V8SEE+" -"B @(" P># P,#,Y.6)D+" P>#8W-#8V
M.#@P+" P>&(T,3&%C9C0R,V(R+" -"B @(" P>&-A.#$U86(S
M+" P>#5A-C,Y-64W+" P>#,P,F$V-V,U+" P>#AB9&(T-#9B+" -"B @(" P
M>#$P.&8X9F$T+" P>#$P,C(S961A+" P>#DR8CAB-#AB+" P>#=F,SAD,&5E
M+" O*B P>#$W," @(" J+PT*(" @(#!X86(R-S Q9#0L(#!X,#(V,F0T,34L
M(#!X

Cryptography-Digest Digest #920

[Digestifier]

Cryptography-Digest Digest #920, Volume #8   Sun, 17 Jan 99 13:13:01 EST

Contents:
  Re: read and pass please!!! ("Jay")
  Re: Too simple to be safe ("Kazak, Boris")
  Trying to find simple, yet effective implementation of crypto... ("Tim Mavers")
  Feistel network ([EMAIL PROTECTED])



From: "Jay" <[EMAIL PROTECTED]>
Subject: Re: read and pass please!!!
Date: Sun, 17 Jan 1999 08:35:56 -0500

PLEASE DO NOT DO THIS! IT IS A HOAX

This message has periodically been sent again and again by well meaning
people, but it just clutters up mail boxes. The doctor mentioned had to
change his phone number. The American Cancer Society is NOT involved in any
such program.

There are others like this. Before you forward anything like this please
check:

http://www.hoaxkill.com/
http://kumite.com/myths/
http://www.urbanlegends.com
http://www.snopes.com/

Jay

Angel wrote in message <[EMAIL PROTECTED]>...
>
>Dear All,
>
>I just received this mail from a friend of mine in my college.  Please
>respond to it. It will just mean employing a little bit of time and
>won't cost you a penny.   All it needs is the heart for you to send
>this mail.
>
>PLEASE pass this mail on to everybody you know.  It is the request
>of a little girl who will soon leave this world as she has been a
>victim of the terrible disease called CANCER.
[...]
>this to as many people as possible, you can give her and her family a
>little hope, because with every name that this is sent to, The
>American Cancer Society will donate 3 cents per name to her treatment
>and recovery plan.   One guy sent this to 500
>people





--

From: "Kazak, Boris" <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 10:53:54 -0500
Reply-To: [EMAIL PROTECTED]

Paul Rubin wrote:
> (snip)
> How did you generate
> the 150 kbyte file?  For example if it came from a 16-bit rand()
> generator, it has almost no real entropy and so it is useless.
> There are a lot of opportunities to mess up.
==
   My randomizing procedure is inspired by the convolution 
algorithm, which is very common in digital filtering studies. 
Essentially the convolution is described by the following 
formula, sorry, it is not easy to reproduce it in the ASCII text file.
If K[n] is some random byte sequence and G[i] is some file
( of unknown origin, it can be any .BMP or .WAV file):
 *
n=N
  CONV[m] = SUM {G[n+m]*K[n]} ;  
n=1

where N is the number of points in K[n]
 *
Obviously, the number of points in G[i] must be big enough to 
allow this procedure.  The random sequence K[n] can be, for example,
the first 64 bytes of PI, multiplication is unsigned Mod 255, all 
eventual carries and overflows are disregarded (anyway, this is meant 
to be a one-way procedure). 

> 
> >I was not going for "fancy", this is just practical.
> >And this scheme seems to work with any block cipher, regardless...
> >Additionally, we use KOI-8 encoding for Russian plaintext, this
> >hopefully will make the attacks a little more difficult, if they
> >will use the English-plaintext stereotype :)
> 
> I still don't see the need for the 150 kbyte file.  It creates a
> vulnerability since if the file is seized, the game is over.
=
In this you are absolutely correct, but this applies to any key seizure.
=
> It might even be better to just keep re-using the same key.
> If you don't want to do that, use a single permanent memorized
> key (passphrase) to encrypt a temporary key which is different
> for each message.
> 
> Best would be to use a public key method like Diffie-Hellman key
> exchange for every message to create a new secret key, and destroy
> each new secret key after using it once.

Yes, I am thinking on going ahead with this, especially since NSA
declassified its KeyExchangeAlgorithm (along with Skipjack). This 
KEA is simple, all the constants are provided in the document, so 
one must only install an appropriate BigNumber math package.
Still my 150 Kb random file may serve as a source even in this case.

--

From: "Tim Mavers" <[EMAIL PROTECTED]>
Subject: Trying to find simple, yet effective implementation of crypto...
Date: Sun, 17 Jan 1999 10:15:35 -0600

I am trying to implement a system where my program can send messages to a
server (also written by me) who then can reply (or send messages) to another
client (my program as well).  The messages have to be encrypted.  The
messages basically contain a meta-protocol that the programs use to
communicate with each other (the server parses the messages and determines
what to do).  Since I don't want anyone knowing my protocol (it's a very
basic one, but if known by all, m

Cryptography-Digest Digest #592

[Digestifier]

Cryptography-Digest Digest #592, Volume #10  Fri, 19 Nov 99 16:13:03 EST

Contents:
  Re: AES cyphers leak information like sieves (Tim Tyler)
  GT-1 Consortium  (MikeAt1140)
  Re: AES cyphers leak information like sieves (Anne & Lynn Wheeler)
  Re: technical writing skills required! (Medical Electronics Lab)
  Re: Public Keys Comparison (David A Molnar)
  Re: GT-1 Consortium  ("Michael Scott")
  Re: Bypass analysis of cipher machines (Troed)
  Apparently, Hushmail does work (John Savard)
  Re: rotors (Tom St Denis)
  Re: Ultimate Crypto Protection? (John Savard)



From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: AES cyphers leak information like sieves
Reply-To: [EMAIL PROTECTED]
Date: Fri, 19 Nov 1999 17:12:04 GMT

Jerry Coffin <[EMAIL PROTECTED]> wrote:
: In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
:> Jerry Coffin <[EMAIL PROTECTED]> wrote:

:> : Those who really believe that simply re-transmitting a message is 
:> : reasonable if it doesn't come through intact should read _Between Silk 
:> : and Cyanide_ continuously until they learn better.
:> 
:> What are you talking about?  Retransmitting a cyphertext presents
:> practically no security risk at all.

: I'm not talking about a risk of security due to the message being 
: intercepted.  I'm talking about a risk (in some cases quite extreme 
: risk) of the person sending it being found and killed, for one 
: example.

I see.  /Sometimes/, there are problems with sending more than one
message.  /Sometimes/ the message content may be so critical that
your recipient must get it first time for it to be of use.

However, resending messages, is not /necessarily/ unreasonable.
In fact resending entire messages is often the best way of coping
with garbles.

I'd wholeheartedly agree that resending messages can be dangerous
*in some circumstances*.  However, that is no reason to malign
resending messages in general - as often there is no problem with
doing so, and it is the correct thing to do.

[snip]

:> Keeping compression separate is a good idea.  However, a "chaining mode"
:> is not a necessary component of a cypher.  For one thing it necessarily
:> introduces a serial component to encyphering.  If you have a parallel
:> machine available, introducing something like this may kill performance.
:> My code is mainly targetted at FPGAs.  In such domains, "chaining modes"
:> are not really on the menu.

: I think I pointed out that ECB can be useful in this sort of 
: situation.  I'll also point out, however, that ECB is NOT the only 
: solution.  Another possibility would be for each device to use CBC, 
: and simply have a number of interleaved streams, each encrypted by one 
: device.  Each device (and therefore each stream) uses a separate IV.  
: Unless you're using such massive parallelism that you expect each 
: device to encrypt only a very small number of blocks [...]

That's the situation I'm thinking about.  In fact, no blocks are involved,
but if they were, each "device" would be handling one block.

Basically, having a chain of operations means that each must be performed
in sequence.  Your proposal about employing multiple streams would
certainly reduce chain length and speed things up.  However, might
it not also adversely affect the overall security, to have all these
messages encrypted with the same key, and only different IVs?

It appears to me that suddenly you need to pay attention to any patterns
in the generation of the IVs - an issue that was of diminished relevance
when each IV came under a separate key...

:> This is a virtue of using error-correction technology.  No matter /how/
:> noisy a channel you are faced with you can still get a 99.99% chance of
:> successful transmission if you throw bandwidth at the problem.

: Yes, if you have sufficient bandwidth to spare you can overcome almost 
: any amount of noise.  Sometimes you just don't have that kind of 
: bandwidth though...

If your problems are that big you either are sending a *very* large file,
or are extremely likely to get errors in each 128-bit block *anyway*.

If you have a probability of error in each bit of approx 1/128, it does
not take much extra bandwidth to give a very high probability of
successful transmission - unless the messages are *very* long.

:> Under the *insanely*-infrequent conditions where you have limited
:> bandwidth, high error rates, no chance of resending a failed message, and
:> you /must/ get some fragments of your message across, this can /still/ be
:> done by splitting the message up.  This reduces it to a cookbook-mode
:> block cypher.  You can /still/ apply block chaining to consecutive
:> messages if you /really/ want.

: IOW, with enough kludges, you can overcome the inherent shortcomings 
: of the particular chaining mode you're advocating...

I'm not advocating *any* sort of chaining mode - I'd prefer no blocks and
no chaining at all most of the tim

Cryptography-Digest Digest #591

[Digestifier]

Cryptography-Digest Digest #591, Volume #10  Fri, 19 Nov 99 14:13:02 EST

Contents:
  Re: A Random Key Cipher Machine (Tom St Denis)
  Re: Fingerprints for encryption alg. (crippa)
  Re: AES cyphers leak information like sieves (SCOTT19U.ZIP_GUY)
  Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
  Re: ATTN Scott Nelson (CoyoteRed)
  Re: Question about enigma rotors (Erik H.)
  Re: What part of 'You need the key to know' don't you people get? (SCOTT19U.ZIP_GUY)
  Re: AES cyphers leak information like sieves (David Wagner)
  Re: Ultimate Crypto Protection? ("Douglas A. Gwyn")
  Re: What part of 'You need the key to know' don't you people get? ("Douglas A. Gwyn")
  Re: Simpson's Paradox and Quantum Entanglement ([EMAIL PROTECTED])
  Re: Backdoor Tactic (Albert P. Belle Isle)
  Re: AES cyphers leak information like sieves (Tim Tyler)



From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: A Random Key Cipher Machine
Date: Fri, 19 Nov 1999 13:14:13 GMT

Typing for the most part is too regular to use as 'random' sampling
points along a smooth sine wave.  You would be sampling at common
points during 'typing bursts'.

Neat idea otherwise.

Tom


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

--

From: crippa <[EMAIL PROTECTED]>
Subject: Re: Fingerprints for encryption alg.
Date: Fri, 19 Nov 1999 15:06:27 +0100

Roger Carbol wrote:
> 
> JPeschel <[EMAIL PROTECTED]> wrote
> 
> >>is it possible to construct an encryption algorithm X which
> >>will give the encrypted message a fingerprint? The fingerprint
> >>will assure any reader of the encrypted message -even a reader
> >>without the appropriate key- that the underlaying plaintext
> >>has been encrypted with the X algorithm.
> 
> >Sure it is.
> 
> Depends on what [EMAIL PROTECTED] means by "assure"
> I suspect.  I don't see any way of eliminating false positives,
> that is, detecting the fingerprint mistakenly in any old
> ciphertext, although certainly it could be made unlikely.
> 
> .. Roger Carbol .. [EMAIL PROTECTED]


Correct interpreted.

Alice sends the enciphered message, having
this fingerprint, to Bob. If Eva intercept the enciphered
message and performs the fingerprint verification she will
conclude that enciphering algorithm X was used.

If you know how the algorithm works performing the fingerprint
verification one could possibly add certain data D to an, by
the unbreakable algorithm Y, enciphered message so that it would
pass the fingerprint verification.

But then the question arise, how should this data D be added
without destroying the encipherment done by algorithm Y?

This is the situation:

M   = plaintext message.
Eub = UnBreakable encipher algorithm (forbidden by ...the world, government
etc.)
Dub = Deciphering algorithm of Eub.
Ex  = legal encipher algorithm accomplishing the fingerprint.
V   = the algorithm for the fingerprint verification. Returns true or false.
Fd  = the Faking Data algorithm giving V(Fd(M))=true for any message M.


1: V(Eub(M)) = false

2: V(Ex(M)) = true

3: How should Fd be constructed such that

   V(Fd(Eub(M))) = true

   and also that we can find/know the reversing
   algorithm RFd of Fd (RFd(Fd(M)) = M ) such that

   Dub(RFd(Fd(Eub(M = M 

   holds ??


If it is impossible to find this Fd and RFd then we are done.
And we could conclude that an enciphering algorithm leaving
a fingerprint is possible.

But alas, we have one situation still to deal with, shown below:

4: V(Ex(Eub(M))) = true

To over come this situation Ex must be able to understand what kind
a message it is about to encipher. The Ex must make sure that M is
a message written in a pre-known language, e.g. English, Swedish,
C++ code etc. But this is most likely infeasable in practice.
(The Ex must at least hold a dictionary and frequency statistics
of the language in question.)


So much for this idea.


-- 
Best Regards

/Christofer

~~~
! Christofer Törnkvist   ! ERICSSON UTVECKLINGS AB!
! ÄL2/UAB/F/V! SOFTWARE ARCHITECTURE LABORATORY   !
! Phone/fax: +46 8 727 57 52 /75 ! Box 1505, SE-125 25 ÄLVSJÖ, SWEDEN !
! [EMAIL PROTECTED]   ! Visiting address: Armborstvägen 1  !
! Take juunk away when mailing   ! Ext: www.ericsson.se/cslab !
!! Int: www-sarc.ericsson.se/public   !
! T H E  o p e n  s o u r c e  a t--- http://www.erlang.org

--

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: AES cyphers leak information like sieves
Date: Fri, 19 Nov 1999 15:08:29 GMT

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Jerry 
Coffin) wrote:
>In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>[ ... ] 
>
>> I'm not certain, but I have difficulty in imagining a "chaining mode"
>> of a block cypher that pr

Cryptography-Digest Digest #919

[Digestifier]

Cryptography-Digest Digest #919, Volume #8   Sun, 17 Jan 99 09:13:05 EST

Contents:
  [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1 (Shannon Appel)



From: Shannon Appel <[EMAIL PROTECTED]>
Crossposted-To: 
alt.security,comp.security.misc,comp.protocols,comp.infosystems.www.misc,alt.answers,comp.answers,news.answers,sci.answers
Subject: [SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1
Date: 17 Jan 1999 13:35:41 GMT

Content-type: text/x-usenet-FAQ;
version=1.1;
title="[SSL-Talk List FAQ] Secure Sockets Layer Discussion List FAQ v1.1.1"
Archive-name: computer-security/ssl-talk-faq
Posting-Frequency: monthly
Last-modified: Nov 16 12:00:00 PST 1998
Version: 1.1.1 (text) Mon Nov 16 12:00:00 PST 1998
URL: http://www.consensus.com/security/ssl-talk-faq.html
Copyright-Notice: (c) Copyright 1996-1998 by Consensus Development Corporation -- All 
Rights Reserved


  SSL-Talk FAQ
Secure Sockets Layer Discussion List FAQ v1.1.1

  Mon Nov 16 12:00:00 PST 1998

   FAQ Maintained by:
  Shannon Appel <[EMAIL PROTECTED]>
Consensus Development Corporation


 The latest edition of this FAQ can always be found at:
  
   

  Copyright (c) 1996-1998 Consensus Development Corporation - All Rights 
  Reserved

* 
Due to the November 15, 1998 dissolution of the SSL-Talk mailing 
list, this will be the last version of this FAQ in its current form. 
It will be replaced by a more general TLS & SSL FAQ in the near 
future that is not tied to any mailing list or newsgroup. 
*

All information contained in this work is provided "as is." All
warranties, expressed, implied or statutory, concerning the accuracy
of the information of the suitability for any particular use are
hereby specifically disclaimed. While every effort has been taken to
ensure the accuracy of the information contained in this work,
the authors assume(s) no responsibility for errors or omissions or
for damages resulting from the use of the information contained
herein.

This work may be copied in any printed or electronic form for
non-commercial, personal, or educational purposes if the work is not
modified in any way, provided that the copyright notice, the notices 
of any other author included in this work, and this copyright 
agreement appear on all copies.

Consensus Development Corporation also grants permission to
distribute this work in electronic form over computer networks for
other purposes, provided that, in addition to the terms and
restrictions set forth above, Consensus Development Corporation
and/or other cited authors are notified and that no fees are charged
for access to the information in excess of normal online charges
that are required for such distribution.

This work may also be mentioned, cited, referred to or described
(but not copied or distributed, except as authorized above) in
printed publications, on-line services, other electronic
communications media, and otherwise, provided that Consensus
Development Corporation and any other cited author receives
appropriate attribution.

Comments about, suggestions about, or corrections to this document
are welcomed. If you would like to ask us to change this document
in some way, the method we appreciate most is for you to actually
make the desired modifications to a copy of the posting, and then to
send us the modified document, or a context diff between the posted
version and your modified version (if you do the latter, make sure
to include in your mail the "Version:" line from the posted
version). Submitting changes in this way makes dealing with them
easier for us and helps to avoid misunderstandings about what you
are suggesting.

Many people have in the past provided feedback and corrections; we
thank them for their input.

In particular, many thanks to:

Christopher Allen <[EMAIL PROTECTED]>
Shannon Appel <[EMAIL PROTECTED]>
Nelson Bolyard <[EMAIL PROTECTED]>
Tim Dierks <[EMAIL PROTECTED]>
Eric Greenberg <[EMAIL PROTECTED]>
Charles Neerdaels <[EMAIL PROTECTED]>
Bruce Schneier <[EMAIL PROTECTED]>
Tom Weinstein <[EMAIL PROTECTED]>
Jonathan Zamick <[EMAIL PROTECTED]>

Remaining ambiguities, errors, and difficult-to-read passages are
not their fault. :)

==

Cryptography-Digest Digest #918

[Digestifier]

Cryptography-Digest Digest #918, Volume #8   Sun, 17 Jan 99 09:13:05 EST

Contents:
  Re: Metaphysics Of Randomness ("Douglas A. Gwyn")
  Re: Sarah Flannery and the "Cayley-Purser" Algorithm ("Douglas A. Gwyn")
  Re: Sarah Flannery and the "Cayley-Purser" Algorithm ("Douglas A. Gwyn")
  Re: Cayley-Purser algorithm? (David Formosa (aka ? the Platypus))
  Re: Too simple to be safe ([EMAIL PROTECTED])
  Re: sci.crypt intelligence test. (Jerry Park)
  Re: Question on current status of some block ciphers in AC2 ([EMAIL PROTECTED])



From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Metaphysics Of Randomness
Date: Sun, 17 Jan 1999 07:02:48 GMT

"R. Knauer" wrote:
> In simple terms, Chaitin means by the term "reason" a simplifying
> algorithm which reduces the complexity of the number. If you can
> substantially simplify the generation of a number algorithmically, you
> have given a "reason" for its existence. If you cannot, then the
> number happens without a reason, i.e., randomly.

There are also limitations to this point of view.
For example:  Given a truly random bit generator,
inevitably *some* finite bit sequences are more
highly ordered (in the Chaitin sense) than others,
but there is no more "reason" behind them than for
the others.  While the "laws of nature" appear to
most humans to be highly nonrandom, keep in mind
that evolution has imposed upon us highly selective
sensory/perceptual/conceptual filters, so our
attention is naturally focussed on the orderly
portions of nature.  Probably that has something
to do with the difficulty we have in nailing down
the notion of "randomness".

--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Sarah Flannery and the "Cayley-Purser" Algorithm
Date: Sun, 17 Jan 1999 07:10:00 GMT

[EMAIL PROTECTED] wrote:
>   ... She won at
>   the weekend and left the judges unable fully to comprehend
>   her project. They described her work as "brilliant" ...

>From the quoted press article, it is impossible to determine
anything about the possible merit of this strangely named
algorithm.

There is an overview of the progress made against RSA in the
latest Notices of the AMS.  I gather from the Flannery press
article, by omission, that there has been no comparable effort
made against Flannery's algorithm, so the claim that it is as
secure as RSA is surely premature.

--

From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Sarah Flannery and the "Cayley-Purser" Algorithm
Date: Sun, 17 Jan 1999 07:23:57 GMT

Bauerda wrote:
> Their have certainly been public key algorithms based on matrices ...

The fact (if it is one) that matrices are involved means nothing,
really.  Real numbers can be treated as 1x1 matrices if you wish.
Matrices are merely one of many mathematical tools, and in themselves
don't have any bearing on the security of an algorithm (pro or con).

--

From: [EMAIL PROTECTED] (David Formosa (aka ? the Platypus))
Subject: Re: Cayley-Purser algorithm?
Date: 17 Jan 1999 04:29:41 GMT

In article <[EMAIL PROTECTED]>, Doug Stell wrote:
>On Fri, 15 Jan 1999 15:16:45 GMT, [EMAIL PROTECTED] wrote:
>
>>Sorry.  Once the method has been published, it CAN NOT be patented in
>>the US.
>
>Have the rules changed? Wasn't RSA patented in the U.S. after it was
>published, else publication would have been squashed? Isn't RSA's
>publication also the reason that it isn't patented outside the U.S.?
>At least this is what I thought Ron and Jim both told me.

IIRC the EU doesn't have rules that allow patenting of algorthyums.

-- 
Please excuse my spelling as I suffer from agraphia. See
http://www.zeta.org.au/~dformosa/Spelling.html to find out more.
How to win arguments on usenet http://www.zeta.org.au/~dformosa/usenet.html


--

From: [EMAIL PROTECTED]
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 07:56:48 GMT

In article <[EMAIL PROTECTED]>,
  Nathan Kennedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> > The cryptosystem proposed seems to assume that irrational
> > numbers are random enough for cryptographic purposes. This
> > is not always the case. Some irrational numbers can have
>
> On the other hand the conjecture that, say, the digits of pi are normal, is
> probably almost as safe as saying that factoring is hard.
>
> > a long string of zeros, for example. XORing this section
> > of an irrational number with a plaintext would reveal the
> > plaintext. Taking the sqrt(prime) would usually produce a
> > random looking string, but in the 135 bit range, you are
> > in unknown territory as far as that goes. You might rarely
> > pick a poor choice which has a weak sqrt for XOR purposes.
>
> I read somewhere on an irrational site, that PI has been so far been found
> to be normal, whereas sqrt(2) is slightly less random, and sqrt(3) is
> slightly less ran

Cryptography-Digest Digest #590

[Digestifier]

Cryptography-Digest Digest #590, Volume #10  Fri, 19 Nov 99 09:13:03 EST

Contents:
  Re: What part of 'You need the key to know' don't you people get? (Tom St Denis)
  Re: NSA should do a cryptoanalysis of AES (Doug Stell)
  Re: AES cyphers leak information like sieves (Jerry Coffin)
  Re: Group English 1-1 all file compressor (William Rowden)
  Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
  Re: What part of 'You need the key to know' don't you people get? (Johnny Bravo)
  Re: Backdoor Tactic (Johnny Bravo)
  Re: more about the random number generator (Scott Nelson)
  Re: Backdoor Tactic (Guy Macon)
  Re: AES cyphers leak information like sieves (Volker Hetzer)
  A Random Key Cipher Machine (Mark Adkins)



From: Tom St Denis <[EMAIL PROTECTED]>
Subject: Re: What part of 'You need the key to know' don't you people get?
Date: Fri, 19 Nov 1999 05:02:37 GMT

In article <812dar$p0q$[EMAIL PROTECTED]>,
  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote:
> In article <811eqh$39q$[EMAIL PROTECTED]>, Tom St Denis
<[EMAIL PROTECTED]> wrote:
> >In article <811236$2ija$[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY) wrote
> >>are you a complete fool where did you get such a rediculus
number.
> >> Are you stuoid enough to think that the number 26 is a binary
number.
> >> You really are full of shit Mr Tom. Each wheel is a specail
arrangement
> >> of 26 characters and don't forget the plug borad in the front of
machine.
> >
> >
> >Let's do some math review for the newbie here. 26 positions per wheel
> >gets you 26^x = 2^128, therefore x = log26(2^128) = ~28
> >
> >Sorry if this is too complex for the mastermind behind scottu
ciphers...
> >
> >Tom
> >
>
>Well Tom I have to admit I have no idea what you are trying to do.
> Maybe you can tell me how big my key should have been for scott4u
> which is like wiring up a wheel with only 16 character instead of the
> 26 as in an engima wheel. Maybe you found something. But I doubt it.

I messed up the math.  Sorry. [see my post 'rotors'].

Tom


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

--

From: [EMAIL PROTECTED] (Doug Stell)
Subject: Re: NSA should do a cryptoanalysis of AES
Date: Thu, 18 Nov 1999 23:52:40 GMT

On Thu, 18 Nov 1999 13:23:51 GMT, [EMAIL PROTECTED] wrote:

>I think one of the issues relating to this is trust.  When Clipper was
>announced by the NSA and they tried to make people use it, did anybody
>really trust it?  No.  If the NSA were to create an algorithm and enter
>it in AES, I think everyone would be wary. 

Perception counts for a lot.

The Clipper algorithms, SKIPJACK and KEA, are held in suspect, because
of how Clipper used them. However, SKIPJACK is probably a good
algorithm, because it is used in other Type 2 applications when its
strength is expected to be consistent with its key length. Likewise,
the corresponding key agreement algorithm, KEA, is a perfectly sound
algorithm and is used in similar circumstances, often along with
SKIPJACK 

For two decades, we seriously wondered if NSA strengthened or weakened
DES by their involvement. We now know that they made it as strong as
it can be, given the key size they imposed upon it.

--

From: [EMAIL PROTECTED] (Jerry Coffin)
Subject: Re: AES cyphers leak information like sieves
Date: Thu, 18 Nov 1999 23:10:07 -0700

In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...

[ ... ] 

> I'm not certain, but I have difficulty in imagining a "chaining mode"
> of a block cypher that produces very much diffusion of information
> between blocks.  If using a fixed size, small block block cypher, you
> should probably applu diffusion to your message first.

Keep in mind that ScottXXu (for one example) is really a block cipher 
with quite a small block size, the uses a chaining mode to get the 
effect of treating the entire file as a single large block (in at 
least some respects).

[ ... ] 

> Hell, if it's really important, *and* there's no chance to retransmit it,
> *and* the channel is really noisy, *and* the bandwidth is so limited you
> can apply little error correction,

[ ... ] 

Let's face reality: you're ultimately talking about one fairly 
specific situation, while AES isn't.  You're basically talking about 
how to design a complete secure system for use almost exclusively in a 
single set of circumstances: sending messages over the Internet.  If 
it makes you happy to hear somebody say that using AES, (or any AES 
finalist) all by itself is insufficient to ensure secure 
communications in this environment, and that it's possible to improve 
on that, I (for one) have no hesitation in agreeing.

At the same time, I'll ask that YOU keep in mind that AES is intended 
to be one (relatively small) piece in a relatively large puzzle.  AES 
is intended purely and only as an encryption algorithm, nothing more.

Cryptography-Digest Digest #917

[Digestifier]

Cryptography-Digest Digest #917, Volume #8   Sun, 17 Jan 99 02:13:03 EST

Contents:
  Secure Filesystem Questions (Anonymous)
  Re: Too simple to be safe (Nathan Kennedy)
  Re: Too simple to be safe (Nathan Kennedy)
  file size of encrypted vs. unencrypted data (Grant Karlin)
  Re: Too simple to be safe ("Kazak, Boris")
  Re: Metaphysics Of Randomness (Patrick Juola)
  Re: Too simple to be safe ("Kazak, Boris")
  Re: Too simple to be safe (Michael Hirsch)
  hello! ("ROTA Computer Consultants")
  Re: file size of encrypted vs. unencrypted data (Casey Sybrandy)
  Re: Too simple to be safe (Paul Rubin)
  --- sci.crypt charter: read before you post (weekly notice) (D. J. Bernstein)



From: Anonymous <[EMAIL PROTECTED]>
Subject: Secure Filesystem Questions
Date: 17 Jan 1999 02:39:10 +0100

I've been playing around with TCFS.  It uses a very weak user authentication scheme at 
the 
moment, relying on the user's Linux login password only to authenticate the user.  The 
actual 
64-bit secret key used is stored in a secondary file in /etc/tcfspasswd.  When you 
want to 
start using your key within a secured fs mount point subdir tree, it asks for your 
login password, 
then extracts your encrypted secret key from /etc/tcfspasswd and in turn decrypts it 
using 
unix-style crypt().  It finally puts the decrypted key into a kernel structure where 
it is 
subsequently used for CPC-mode file enc/dec. 

I want to increase the strength of this authentication method.  I plan to increase the 
keysize to 
128 bits, but that is probably irrelevant to my question.  I was thinking along the 
lines of having 
the user enter a passphrase in order to activate his secret key.  I've been rummaging 
around 
inside GnuPG for ideas and examples on how to do this and got some pretty good info 
there in 
terms of secure memory allocations, passphrase manipulation, etc.

Do I lose anything by not even storing the encrypted secret key somewhere on disk?  
That is, 
I say forget about /etc/tcfspasswd, just hash the passphrase down to 128 bits and use 
it 
directly to encrypt/decrypt.  Can I safely ignore using salt?  I mean, if the key 
isn't even stored 
in any form on disk, I don't have to worry about dictionary attacks, right?  Am I 
missing 
something?  The weakest link in the chain here, as I see it, is the passphrase.  That 
I want 
to leave entirely up to the user.  If they choose a lame passphrase then tough 
noogies. 

Second question:  If I use RIPEM-D160 to hash the passphrase down to 160 bits and then 
select only 128 of those bits to use as the key, do I gain anything over simply using 
a 128-bit 
hash algorithm?  

Third (and last) question:  Is it true that with this scheme I don't even need a 
random number 
generator?  Aside from CBC Init Vectors, which I haven't found too much discussion on, 
I 
can't see where I even need one.

Thanks for any and all responses.




--

From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 02:05:25 +0800

"Kazak, Boris" wrote:

> Like that the information about the key is communicated in the open
> text, and the key is never reused. No digital signatures, no CA's.
> 
>  Any comments?RespectfullyBNK

Just one.  Why do you do this, i.e., as opposed to a trusted cipher? 
Obviously key exchange isn't a problem as you already have 150K key in
common.  If you need something extremely simple, you could use an RC
cipher, and if you need something paranoidly trusted, you could use 3DES or
4DES or 3DES+Blowfish+RC5+Twofish+RC6 in which case if even one of these
trusted ciphers (well, some of them are trusted, I think most
cryptographers would bet on it even if they wouldn't certify it) does its
job, and you implement it right, it would be secure.

Or is it just a tradeoff, guaranteed security for a little bit more
overhead and less coding time?

Nate

--

From: Nathan Kennedy <[EMAIL PROTECTED]>
Subject: Re: Too simple to be safe
Date: Sun, 17 Jan 1999 02:16:24 +0800

[EMAIL PROTECTED] wrote:

> The cryptosystem proposed seems to assume that irrational
> numbers are random enough for cryptographic purposes. This
> is not always the case. Some irrational numbers can have

On the other hand the conjecture that, say, the digits of pi are normal, is
probably almost as safe as saying that factoring is hard.

> a long string of zeros, for example. XORing this section
> of an irrational number with a plaintext would reveal the
> plaintext. Taking the sqrt(prime) would usually produce a
> random looking string, but in the 135 bit range, you are
> in unknown territory as far as that goes. You might rarely
> pick a poor choice which has a weak sqrt for XOR purposes.

I read somewhere on an irrational site, that PI has been so far been found
to be normal, whereas sqrt(2) is slightly less random, and sqrt(3) is