Cryptography-Digest Digest #168

2001-04-17 Thread Digestifier

Cryptography-Digest Digest #168, Volume #14  Tue, 17 Apr 01 14:13:01 EDT

Contents:
  Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
  Re: Reusing A One Time Pad ("Tom St Denis")
  Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
  Re: Note on combining PRNGs with the method of Wichmann and Hill ("Brian Gladman")
  Re: Reusing A One Time Pad ("Tom St Denis")
  Re: Reusing A One Time Pad (SCOTT19U.ZIP_GUY)
  Re: Reusing A One Time Pad ("Tom St Denis")
  Re: Choosing a Smartcard/Crypto Chip for PKI on Win2K ("Ryan Phillips")



From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: Re: Reusing A One Time Pad
Date: 17 Apr 2001 17:04:59 GMT

[EMAIL PROTECTED] (Tom St Denis) wrote in
4u_C6.31062$[EMAIL PROTECTED]: 


"SCOTT19U.ZIP_GUY" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 [EMAIL PROTECTED] (Joseph Ashwood) wrote in
 ePD6covxAHA.328@cpmsnbbsa07: 

 The moment you reuse *any* portion of the pad, the security
 immediately falls to precisely 0. That's a simple fact of life
 (assuming you are using a standard XOR based pad). There is no
 getting around that, no amount of postulating will get around the
 mathematic problems involved, your idea is plain and simply insecure.
 Joe

Actually the security is not ZERO. You may have reduced the
 ppssible set of the messages but as long as there is more than
 one plausble decryption it is not zero. But I agree the more
 you use the less secure and its not to had to reach ZERO.
 Especailly if the plain text file was known to be compressed
 as part of the encryption package as in PGP.

Um to disprove anything you have said for the past 8 years or so.. an
OTP is secure even if the message was compressed with deflate. so
tell me again how the compression hurts?


   I don't wish to get in a long argument with you since you really
don't want to learn. But I will clarify what I think your 
misunderstanding is.  First of all we both know that a OTP is secure.
Joe was commenting that if you repeat one bit its not secure at all.
We all know or should know that if you use it over and over again its
not secure. IF a "one time Pad" is used correctly. Meaning "one time"
then the encryption is secure regardless of what compression was used.

   As to weakness of using nonbijecetive file compression in encryption
systems I think you know where I stand on that after years of trying
to get you to understand it.


David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE "OLD VERSIOM"
http://www.jim.com/jamesd/Kong/scott19u.zip
My website http://members.nbci.com/ecil/index.htm
My crypto code http://radiusnet.net/crypto/archive/scott/
MY Compression Page http://members.nbci.com/ecil/compress.htm
**NOTE FOR EMAIL drop the roman "five" ***
Disclaimer:I am in no way responsible for any of the statements
 made in the above text. For all I know I might be drugged or
 something..
 No I'm not paranoid. You all think I'm paranoid, don't you!


--

From: "Tom St Denis" [EMAIL PROTECTED]
Subject: Re: Reusing A One Time Pad
Date: Tue, 17 Apr 2001 17:19:22 GMT


"SCOTT19U.ZIP_GUY" [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]...
 [EMAIL PROTECTED] (Tom St Denis) wrote in
 4u_C6.31062$[EMAIL PROTECTED]:

 
 "SCOTT19U.ZIP_GUY" [EMAIL PROTECTED] wrote in message
 news:[EMAIL PROTECTED]...
  [EMAIL PROTECTED] (Joseph Ashwood) wrote in
  ePD6covxAHA.328@cpmsnbbsa07:
 
  The moment you reuse *any* portion of the pad, the security
  immediately falls to precisely 0. That's a simple fact of life
  (assuming you are using a standard XOR based pad). There is no
  getting around that, no amount of postulating will get around the
  mathematic problems involved, your idea is plain and simply insecure.
  Joe
 
 Actually the security is not ZERO. You may have reduced the
  ppssible set of the messages but as long as there is more than
  one plausble decryption it is not zero. But I agree the more
  you use the less secure and its not to had to reach ZERO.
  Especailly if the plain text file was known to be compressed
  as part of the encryption package as in PGP.
 
 Um to disprove anything you have said for the past 8 years or so.. an
 OTP is secure even if the message was compressed with deflate. so
 tell me again how the compression hurts?
 

I don't wish to get in a long argument with you since you really
 don't want to learn. But I will clarify what I think your
 misunderstanding is.  First of all we both know that a OTP is secure.
 Joe was commenting that if you repeat one bit its not secure at all.
 We all know or should know that if you use it over and over again its
 not secure. IF a "one time Pad" is used correctly. Meaning "one time"
 then 

Cryptography-Digest Digest #168

2000-11-16 Thread Digestifier

Cryptography-Digest Digest #168, Volume #13  Thu, 16 Nov 00 15:13:00 EST

Contents:
  Re: Big-block cipher, perhaps a new cipher family? (Mok-Kong Shen)
  Re: so many fuss about impossibility to backtrace from MD to original  ("Douglas A. 
Gwyn")
  Re: Hitachi - on what grounds ?? ("Douglas A. Gwyn")
  Re: Hitachi - on what grounds ?? (Mok-Kong Shen)
  Re: vote buying... (David Schwartz)
  Re: Q: fast block ciphers (David Schwartz)
  Re: vote buying... ("Frog2000")
  Re: vote buying... ("Frog2000")
  Re: Anyone has read / poses / is found of book by M.Schroeder(not the  ("John A. 
Malley")
  Re: Hitachi - on what grounds ?? ("Paul Pires")
  Re: vote buying... (Paul Rubin)
  Re: Q: fast block ciphers (Tom St Denis)
  Re: vote buying... (Eric Lee Green)



From: Mok-Kong Shen [EMAIL PROTECTED]
Subject: Re: Big-block cipher, perhaps a new cipher family?
Date: Thu, 16 Nov 2000 19:32:55 +0100



Manuel Pancorbo wrote:
 
   Mok-Kong Shen [EMAIL PROTECTED] wrote:
 
  It is not clear in your description how the 'diffusion' is
  achieved through stream encryption. A stream cipher encrpyts
  each 'unit' independent of the other. The 'state' of the
  cipher changes with each unit, but this is generally
  independent of the content of the plaintext unit being
  processed. So there is no 'interaction' between the units.
 
 Should I name it "stream cipher with feedback"? In my design, state
 depends on the input. Anyway, let me explain how it works.
 
 As I said the chosen unit length is 32 bits. The key (K) can be 128 to
 256 bit long (in 32 bit steps); let's take 128 bits i.e. 4 units. The
 state vector (S) is also 4 units long.
 
 At the beginning the state vector is filled up with the key:
 S - K
 In the forward encryption each plaintext unit is ciphered this way:
 
 P'[0] = F(P[0], S[0], S[1])
 S[1] = G(P[0], P'[0])
 .
 P'[1] = F(P[1], S[1], S[2])
 S[2] = G(P[1], P'[1])
 .
 
 And so on. The state cycles over itself (S[0], S[1], S[2], S[3], S
 [0],...). F and G are two 32-bit nonlinear functions. Both propagate
 any single bit change of the P[0] input to 16 bits on the output P'[0]
 and to 24 bits on the new state unit S[1]; in the next step S[1]
 carries the (imperfect) diffusion of P[0] again to F and G which
 amplify it to 32 bits in P'[1] (and S[2]).
 
 You can see how avalanche works forward. At the end a new encryption
 pass is performed backwards:
 
 S - K
 .
 C[N-1] = F(P'[N-1], S[0], S[1])
 S[1] = G(P'[N-1], C[N-1])
 .
 C[N-2] = F(P'[N-2], S[1], S[2])
 S[2] = G(P'[N-2], C[N-2])
 
 The result is that any single bit change in the plaintext packet
 propagates to the full ciphertext packet (except perhaps if the change
 occurs in the last units).
 
 The point is that it doesn't really matter how F and G are built,
 provided a minimum diffusion, unlinearity and operations economy (I
 think). Anyway I can give details in a further post.
 
 
  You can also use any common block cipher to do chaining
  in the forward direction and, after having processed the
  whole file, do a second encryption pass in the backward
  direction. (This is a known method of forcing the opponent
  to process the whole file, as also mentioned previously in
  several threads of the group.) In fact, the block cipher
  is doing 'stream' encryption here if you look on the block
  as a single 'unit' of the 'stream'.
 
 My goal is to avoid the repetitive rounds and the key scheduling of
 block ciphers, but giving the same diffusion power and disorder. If
 possible, giving the same strength ;-)

But in the scheme you described there are the functions
F and G which you don't specify in detail. If the F is
not good, you wouldn't have good diffusion. One can have
a combination of stream and block techniques. I designed
one with a block size of 640 bits driven by a PRNG with
feedback to the PRNG by hash values obtained during the
processing and with block chaining. In other words, the
state of the PRNG is influenced by the plaintext blocks
and the processing of the blocks is determined by the
PRNG outputs and the successive blocks are chained. See 
my web page.

M. K. Shen

http://home.t-online.de/home/mok-kong.shen

--

From: "Douglas A. Gwyn" [EMAIL PROTECTED]
Subject: Re: so many fuss about impossibility to backtrace from MD to original 
Date: Thu, 16 Nov 2000 17:51:03 GMT

[EMAIL PROTECTED] wrote:
 Birthday Paradox (if you bring random people into a room, you can only
 have 20 of them on average before 2 of them have the same birthday)

That's not accurate; it's 23 people and the "averaging" is over
the ensemble of sets of 23-random-people, or better expressed:
if you randomly select a sample of 23 people from the whole
population, the probability is greater than 0.5 that at least 2
of that sample were born on the sa

Cryptography-Digest Digest #168

2000-02-20 Thread Digestifier

Cryptography-Digest Digest #168, Volume #11  Sun, 20 Feb 00 11:13:01 EST

Contents:
  Re: Is Phi perfect? (Frank the_root)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (lordcow77)
  Re: OAP-L3 Encryption Software - Complete Help Files at web site (lordcow77)
  Re: NSA Linux and the GPL (John Savard)
  ISIT2000 -crypto (Quisquater)
  Re: NIST publishes AES source code on web (John Savard)
  Re: Biggest keys needed (was Re: Does the NSA have ALL Possible PGP  keys?) (David A 
Molnar)
  Re: Using virtually any cipher as public key system? (David Hopwood)
  Re: EOF in cipher??? (David Hopwood)
  Re: EOF in cipher??? (David Hopwood)
  Re: EOF in cipher??? (David Hopwood)



From: Frank the_root [EMAIL PROTECTED]
Subject: Re: Is Phi perfect?
Date: Sun, 20 Feb 2000 14:24:53 GMT



Xcott Craver left in some server logs :
 
 Frank the_root  [EMAIL PROTECTED] wrote:
 Hi,
 
 Hi, Frank the Root,
 
 I always thought that the Euler's Phi fonction ( Phi(n) ) was the
 fonction that gives the number of numbers relatively prime to n and
 smaller than n by the multiplication of each primes factors of n reduced
 by one.
 
 That's not how Phi(n) is defined.
 
 When n is a product of distinct primes pq (as occurs in RSA,)
 it is true that Phi(n) = Phi(pq) = (p-1)(q-1).  However, this
 is a special case:  in general, Phi(n) is defined as
 
   Phi(n) = n * (1 - 1/p)(1 - 1/q)(...)
 
 where p,q,... are the distinct prime factors of n.  So:
 
 For exemple: Let's determine the number of numbers relatively prime to
 125: 125 = 5³, so we can see that at each 5 numbers, 4 of them are
 relatively prime to 125. 125 × (5/4) = 42 != (5-1)(5-1)(5-1)
 
 Phi(125) = 125*(1-1/5) = 125*(4/5) = 100.
 
 Phi(9) (3-1)(3-1) != 6
 
 Phi(9) = 9*(1-1/3) == 6
 
 Phi(16): (2-1)(2-1)(2-1)(2-1) != 8
 
 Phi(16) = 16*(1-1/2) == 8
 
 Phi(49): (7-1)(7-1) != 42
 
 Phi(49) = 49*(1-1/7) == 42
 
 Frank
 -Xcott


Thanks, your exemple is really the most "visual" one. Thanks to all.


Frank

--
Ceux qui rêvent le jour savent des choses qu'ignorent ceux qui rêvent la
nuit.

--

Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
From: lordcow77 [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Date: Sun, 20 Feb 2000 06:37:55 -0800

Actually, most educated people knew that the Earth was spherical
when Columbus initiated his voyage. They did underestimate the
size of the world, thus allowing the expedition to be funded in
the first place.




* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


--

Subject: Re: OAP-L3 Encryption Software - Complete Help Files at web site
From: lordcow77 [EMAIL PROTECTED]
Crossposted-To: talk.politics.crypto,alt.privacy
Date: Sun, 20 Feb 2000 06:49:35 -0800

In article [EMAIL PROTECTED], Anthony Stephen
Szopa [EMAIL PROTECTED] wrote:
Obviously you claim to be unimpressed with my random number
generator
and the processing done on this output to generate the OTP
files in
OAP-L3 encryption software.


True; why use your PRNG when there are others that have
withstood far more attention (ie. RC4, SEAL)?

Are you also saying that the OTP file management used in the
software
is also worthless?

Let's say you use your own random numbers and just use OAP-L3
to
encrypt and manage your own OTP files.  Are you saying no one
should
do this because you merely say so with no supporting arguments?

Yes. Your user interface looks like it was designed by a person
who has no conception of GUI design. It does not appear to be
event-based at all, as it is centered on a series of uni-modal
dialog boxes. There are no "wizards" for novice users and no
multi-document interface system for more advanced users.


What about the utility files included with the software?  You
are
saying that it should be of no interest to anyone to have a
utility
program to look at a random number file and provide them with a
frequency for each random number in the file?

#include ...

int main(void)
{
   FILE *fin;
   struct stat fs;
   int arr[256];
   int fsize;
   int i;
   char c;

   fin=fopen("foo","rb");
   stat("foo",fs);
   fsize=fs.st_size;
   for(i=0;i255;i++){arr[i]=0};
   for(i=0;ifsize;i++){
  fread(c,1,1,fin);
  arr[c]++;
   }
   for(i=0;i255;i++){
  printf("I=%d, n=%d\n",i,arr[i]);
   }

   return EXIT_SUCCESS;
}


Do you think no one should be interested in a utility program
that
will read a file in binary and output the ASCII decimal
equivalent
for each character?

#include ...

int main(void)
{
   FILE *fin;
   stru

Cryptography-Digest Digest #168

1999-09-03 Thread Digestifier

Cryptography-Digest Digest #168, Volume #10   Fri, 3 Sep 99 16:13:03 EDT

Contents:
  Description of SQ ("Kostadin Bajalcaliev")
  Description of SQ ("Kostadin Bajalcaliev")
  Re: 512 bit number factored (SCOTT19U.ZIP_GUY)
  Re: 512 bit number factored (D. J. Bernstein)
  Different Encryption Algorithms ("entropy")
  Re: Alleged NSA backdoor in Windows CryptoAPI (Stephan Eisvogel)
  Re: Alleged NSA backdoor in Windows CryptoAPI (Ian Goldberg)
  Re: ECC, D.S., Fravia,  Ian (Ian Goldberg)
  Re: Implementing crypto algorithms in Fortran. (SCOTT19U.ZIP_GUY)
  Re: Home Invasion Bill Drives U.S. Computer Users across border ([EMAIL PROTECTED])
  Re: IDEA- safe? (jerome)
  Re: Alleged NSA backdoor in Windows CryptoAPI (DJohn37050)



From: "Kostadin Bajalcaliev" [EMAIL PROTECTED]
Subject: Description of SQ
Date: Fri, 3 Sep 1999 20:06:18 +0200

Please send your comments about my Stream cipher. Here is only the
description. If you need more details visit
http://eon.pmf.ukim.edu.mk/~kbajalc or http://members.tripod.com/kbajalc.







The SQ1 Stream Cipher

Kostadin Bajalcaliev
April 26th Street num: 14,
91480 Gevgelija, Macedonia, Europe
[EMAIL PROTECTED]



Abstract: This document describes SQ1 stream cipher. SQ1 is
Cryptographically Secure Pseudo-Random bit generator. A novel feature of SQ1
is its hybrid design, using both permutation and variation. It is simple and
easy to implement, suitable for software and hardware implementation.


1. Data Structures

SQ1 is word-oriented algorithm; any word size is supported respecting the
available memory. In order to implement SQ1 data structures below are
required: (given in C notation)

 P[w] – permutation of numbers from 0 to w
V[w] – variation, every element can have any value 0 to w
 Sr   - feedback register

* All data types are W-bit

The word size can be some conventional value 8,16 … bits, but the formal
definition of the algorithm assume any value with respect to available
memory. In the real implementation other variables are used but they are
meter of optimization.


2. Notation and SQ Primitive Operations

SQ1 require only four primitive operations supported by major processor
families.

1. Addition of two words, denoted by “+”, addition is done modulo 2w
2. Bit-wise exclusive OR of words, denoted by XOR
3. A left-rotation of words: the rotation of word x left by y bits is
denoted xy
4. Modulo, x modulo y equal z denoted x mod y = z.

A left-rotation of fields: X’[y]=X[y+z mod field_size], denoted by Xz is
basic operation in SQ1, it is not primitive but easily deliverable from the
primitive operations.


3. Algorithm Specification

According to definition of data structure and primitive operations here is
algorithm formal definition:

/* initialization */
 for j=0 to 2w { P[j]=j; V[j]=0; }


/* generator iteration */
{1} A=P[Sr]; B=P[V[A]];
{2} V[A]=B; Swap P[A], P[B]; P1;
 {3} Out=P[A+B mod 2w];
 {4} Sr1; Sr=Sr+Out;
 Return Out

SQ1 is very simple, you can encode it as a function SQ which produce values
according to its internal state. The state of the generator is defined with
P[], V[] and Sr.
The first step {1} is calculation of indexes A and B according to present
state of the generator. The second step {2} is the transformation of P[] and
V[] according to A and B, P1 is default transformation (the counter). The
third step {3} is calculation of the output value, and the forth {4} step is
changing the value into feedback register.


4. Keying SQ1

SQ as most of Stream Ciphers “keying the generator” is setting the initial
state. Very simple strategy is used. The key stream is feed into Variation
V[] and the key length is feed into Sr. First  22w outputs are discarded to
worm up the generator. Here is the formal definition of keying procedure.

 K[0..L] is the keystream
 L is length of the keystream

 r=0;
 For j=0 to 2w { V[j]=K[r]; r=(r+1) mod L; }
 For j=0 to 22w SQ1();

SQ1() is the generator function described before. The keystream should be
the same word size as P[] and V[] but it is allowed to be smaller to. For
example if w=14, the keystream can be conventional 8-bit character field. If
the w8 (what is very bed idea) that the keystream should be cut in w-bit
peace in order to feed it into V.  The maximal key length allowed using this
strategy is 22w bits, the length of V in bits.


5. Implementation Remarks

This is document is intended to help you implementing SQ1, if you are
interested about the design solutions read the thesis available on-line.
Because of security of the algorithm please follow these remarks:

1. SQ1 is not intending to be secure for any word size or key length. The
word size must be greater than 8bits.
2. Do not use all the bits produced by the generator, discard at least one.
If you need 8-bit values to encrypt files or communication channel use 9-bit
word. The values produced