Cryptography-Digest Digest #996

2001-03-25 Thread Digestifier

Cryptography-Digest Digest #996, Volume #13  Sun, 25 Mar 01 17:13:01 EST

Contents:
  Re: Best encryption program for laptop? (Albert P. Belle Isle)
  Re: compression ratio as a predicter of cipher strength ("John A. Malley")
  Re: compression ratio as a predicter of cipher strength (Frank Gerlach)
  Re: New PGP Flaw Verified By Phil Zimmerman, Allows Signatures to be Forged (Bill 
Unruh)
  Re: compression ratio as a predicter of cipher strength ("Scott Fluhrer")
  Re: 64 versus 128 (or bigger) bits cipher data block (Terry Ritter)
  Re: Valid condition for multiplicative generator? (Terry Ritter)
  Re: compression ratio as a predicter of cipher strength ("Douglas A. Gwyn")
  Re: compression ratio as a predicter of cipher strength ("Douglas A. Gwyn")
  Re: Compression-encryption with a key (Mok-Kong Shen)
  Re: Data dependent arcfour via sbox feedback (Terry Ritter)
  His in-law needs TLA  (STEELEYE)
  Re: Data dependent arcfour via sbox feedback (Mok-Kong Shen)
  Arick wants to eat gentle carrots (Anonymous)
  [INFO] Uppnorth asks to code PGP code (Nomen Nescio)
  [INFO] FBI requires CIA  ("A. Melon")
  [WARNING] Xganon wants to fist-fuck PGP code ("Public " [EMAIL PROTECTED])
  [ANNOUNCE] CIA absolutely needs those Aids-infected NSA  ("Public " 
[EMAIL PROTECTED])
  Arick needs TLA  (Anonymous)
  Tr: Tuttle would love all NSA (Frog2)
  My brother fucking wants gentle jews (Frog2)
  My brother sure loves to print terrible republicans (Frog2)
  Randseed certainly used some politically correct niggers (Frog2)
  Cracow2 used some MIX keys (Nomen Nescio)



From: Albert P. Belle Isle [EMAIL PROTECTED]
Subject: Re: Best encryption program for laptop?
Date: Sun, 25 Mar 2001 14:49:54 -0500
Reply-To: [EMAIL PROTECTED]

On Sun, 25 Mar 2001 04:38:30 GMT, [EMAIL PROTECTED] wrote:

My job is changing, and is going to require me to do some travelling.
I would like to purchase a laptop, and continue to keep my home
finances, and other private data, on it. 
what would be the best way to keep data safe, in case the laptop was
stolen? Which encryption program? And, should it be encryption alone,
or encryption coupled with a secure os like NT?
Thanks. 

Mr. Wilson:

As you may know, no product can provide "access control" to data on a
hard disk by merely restricting the booting or use of the particular
PC to which that disk is presently connected.

"Access" to your hard disk is by means of a standard connector into
which ANY other PC's drive controller cable may be plugged. Whether
the particular one of the millions of Windows machines currently
attached to that plug is yours or someone else's is pretty much
irrelevant.

You can, of course, cryptographically protect the data stored on your
hard drive, IF you  eliminate all of Windows' extra "temporary" copies
of the plaintext, not just the one you replaced with an encrypted
version. This is the fundamental difference between encrypting e-mail
and using encryption as part of storage INFOSEC.

Any supposed data storage security product that doesn't eliminate ALL
copies of plaintext and keying material per DOD 5220.22-M, including
those made by Windows itself in TEMP space and the swapfile (and the
fragments captured into the tail clusters of new files, or into the
interiors of compound files like Word or Excel documents) is an
INFOSEC placebo. 

On the other hand, NO product (including ours) can provide "security"
- merely eliminate specific INSECURITIES. 

I'd suggest that you try to more precisely define the kinds of threats
which you wish to counter. You might find 

 http://www.CerberusSystems.com/INFOSEC/threats.htm

useful in starting the definition of your particular threat profile.

I hope you  find the tutorials and federal cryptographic standards on
our web-site helpful in filtering various possibilities that are open
to you. If you'd like to try our product offerings, that'd be even
better g.



Albert P. BELLE ISLE
Cerberus Systems, Inc.

ENCRYPTION SOFTWARE with
  Forensic Software Countermeasures
http://www.CerberusSystems.com


--

From: "John A. Malley" [EMAIL PROTECTED]
Subject: Re: compression ratio as a predicter of cipher strength
Date: Sun, 25 Mar 2001 12:13:48 -0800


Curtis Williams wrote:
 
 Hi,
 
   An encryption product claims that a ciphertext file should be compressed
 and the compression ration is a predictor of cipher strength (i.e. encrypt a
 file then zip it. if the compression ratio is 0, the encryption is strong).
 Is this valid or snakeoil?
 

Inability to compress the ciphertext output indicates the absence of
patterns or order in the ciphertext. This is a desirable property.  The
detection of patter

Cryptography-Digest Digest #996

2000-10-24 Thread Digestifier

Cryptography-Digest Digest #996, Volume #12  Tue, 24 Oct 00 21:13:01 EDT

Contents:
  Re: On block encryption processing with intermediate permutations (James Felling)
  Re: Rijndael implementations (Tim Tyler)
  Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
  Re: GCHQ Challenge (CiPHER)
  Re: My comments on AES (Bryan Olson)
  Re: Discrete Log Question (Bob Silverman)
  Re: SHA-384 and SHA-512 (John Savard)
  Re: On block encryption processing with intermediate permutations (Mok-Kong Shen)
  Re: I am after a simple one-way encryption algorithm (H.Bruijn)
  Re: I am after a simple one-way encryption algorithm (H.Bruijn)
  Re: idea for spam free email ("G. Orme")
  Re: Finding Sample implementation for DES and IDEA (Steven Wu)
  IEEE P1363 Meeting Announcement ("Jerome A. Solinas")
  Re: How to post absolutely anything on the Internet anonymously (Eric Smith)



From: James Felling [EMAIL PROTECTED]
Subject: Re: On block encryption processing with intermediate permutations
Date: Tue, 24 Oct 2000 14:57:05 -0500



Mok-Kong Shen wrote:

 Bryan Olson wrote:
 
  Mok-Kong Shen wrote:
 
   Suppose one encrypts many double blocks (u, v, u, v) in
   a very long message
  [...]
   I am afraid
   that, by going through 8 cycles it would be extremely
   hard to identify a path like (u,v,u,v)--(x,y,x,y)--
   (e,f,e,f)  -- (j,k,j,k) (say) by examining the
   frequency distribution alone.
 
  I think we've established that the above is a
  misunderstanding of the attack.  In the first part of the
  attack, a single block (two words) constitutes the entire
  message.  In the second part, the entire message is two
  blocks (four words) in size.  The attacker encrypts the same
  short messages many times.  He does not concatenate them
  into one long message and encrypt at once.
 
  The probabilities given in the attack description refer to
  encryption of the one-block (two-word) message and the
  two-block (four-word) message.

 Thanks. It seems now that I am one step further in
 understanding you. Please keep on being patient with me.

 In the one block (u,v) case, through encrypting a few
 hundred times, one achieves that all possible combinations
 of permutations (assumed taking place with equal frequency)
 occur in the inter-cycle permutation processes. With 6
 such processes one gets 2^6 different kinds of ciphertext
 blocks of the type (a,b), each with equal frequency. Is
 that right?

 BTW, I don't understand why do you want to limit to 6
 and don't allow 7 permutation processes which is the
 actual situation. Does that cause difficulties to your
 attack?

Assume that there are N permutation processes. Then
this step generates 2^N blocks all distributed evenly.



 By the same argument, in the two block (u,v,u,v) case
 (with the same u and v as above) one gets 8^6 different
 kinds of ciphertext blocks of the type (c,d,e,f),
 again each with equal frequency. Is that right also?

No. That is where things go a little bit weird.  Watch this simplified
example and see.
I shall use - to indicate encryption, and = {(x,y) 1/K ...} to
indicate possible permutation results(where (x,y) is the perm, and 1/K
is the probability.
(u,v,u,v) - (a,b,a,b) = { (a,a,b,b) 1/6, (a,b,a,b) 1/6, (b,a,a,b) 1/6,
(b,a,b,a) 1/6, (b,b,a,a) 1/6, (a,b,b,a) 1/6}

so it would be 6^N th possibles distributed again uniformly.

Useful to note. 1/3of the time after a round your output is of the same
form as you input.i.e. (a,b,a,b) in (*,#,*,#) out.
then in 1/3^(N-1) of such cases you end N-1 rounds with an imput to the
next round of (x,y,x,y)-(x1,y1,x1,y1)=
{ (x1,x1,y1,y1) 1/6, (x1,y1,x1,y1) 1/6, (y1,x1,x1,y1) 1/6, (y1,x1,y1,x1)
1/6, (y1,y1,x1,x1) 1/6, (x1,y1,y1,x1) 1/6}
Meaning that in 1^3^N cases you have an input to the last round of the
form. (x1,y1, y1,x1) which will output a message of the form
(x1,y1,y1,x1)-(x2,y2,m,n)= which will be permuted prior to output.
since x2 and y2 and m and n should be familiar ( they are in the list of
2^N pairs that the 1 block encryption generated) you now know that{
(x2,y2) or (y2,x2)} and {(m,n) or (n,m)}  are a special pair.  This
allows the attacker to know that those two pairs are related up to round
N-1, and differ only on the last round.  From there it is comparitively
simple to break a 2 round version of whatever is being used. since
birthday attacks can be done. this should work relatively fast. Thus the
effort needed  in total  is 4* the amount of effort needed to break a 2
round version of the cypher  + the effort to achieve such a birthday
coincidence in the output.






 If both answers are yes, I don't yet see how you can
 utilize any frequency information in the ciphertext to
 guide establishing any set of equations. Could you please
 kindly explain?

 Thanks in advance.

 M. K. Shen


--

From: Tim Tyler [EMAIL PROTECTED]
S

Cryptography-Digest Digest #996

2000-01-28 Thread Digestifier

Cryptography-Digest Digest #996, Volume #10  Fri, 28 Jan 00 19:13:01 EST

Contents:
  Help needed on peculiar use of cryptography (Sgwbutcher)
  Read my messages in alt.politics.org.cia - you will be satisfied ! (Markku J. 
Saarelainen)
  Re: Mac encryption algorithm? ("Joseph Ashwood")
  Re: Help needed on peculiar use of cryptography (John Savard)
  Re: Help needed on peculiar use of cryptography (David A Molnar)
  Re: Mac encryption algorithm? (Paul Koning)
  Re: DES Hardare - chips/cores (Paul Koning)
  Re: Pencil  paper cipher question (r.e.s.)
  Re: designing secure backdoors into the system ("Peter K. Boucher")
  Re: designing secure backdoors into the system (Paul Koning)
  Re: designing secure backdoors into the system (Samuel Paik)
  Re: Intel 810 chipset Random Number Generator (Terry Ritter)
  Crypto/Security/Cryptanalysis Papers ("Joseph Ashwood")



From: [EMAIL PROTECTED] (Sgwbutcher)
Subject: Help needed on peculiar use of cryptography
Date: 28 Jan 2000 21:27:34 GMT

Dear forum,

I am an economist and in the course of my work, I often have access to
sensitive information. For example, in a discrimination case, I may have access
to personnel records covering several years for all the employees of a company.
Because I often have to match records across different payperiods, months and
years, a unique identifier is required for each record, often the social
security number. Because of various laws and company policies about the use of
social security numbers or any other identifier, I always sign a
confidentiality agreement with regard to the disclosure of this information.
However, sometimes companies are unwilling to part with information even in the
case of confidentiality agreements.

My question is "is there a way that encryption or a specific use or kind of
encryption can be used so that, say, a social security number can be encrypted
so that the informational value of the cyphertext can be retained but the
plaintext cannot be recovered? and is the code for this method accessible as
the actual implementation may be, depending on the case, in Excel, SAS, C/C++,
Perl or Java?"

I think the most important points are (1) this is permanent encryption--is no
"legitimate" reason why the cyphertext would ever be decrypted and (2) the
domain of the plaintext is very small, 0-9 and short length cyphertext and (3)
the information value of the cyphertext should be the same as the plaintext,
that is, if plaintext A identifies a particular record over 5 years, then
cyphertext A should reference the same records and no others.

One obvious solution is to come up with a new identifier scheme, the problem is
that many IT/DP departments are unwilling to invest the effort and the
databases can be quite large and there may be multiple identifiers.
Additionally, in the case of employee numbers, a simple start at 1001 and go on
approach is how they got their employee numbers to begin with so although you
don't have necessarily the employee number you're looking for, you do have
someone's employee number. This is why I'm looking for something a little more
algorithmic.

Any possible help/suggestions you might be able to provide would be
appreciated.

Thanks,

Steve

==
==
Stephyn G. W. Butcher
Consultant in Labor Economics and Statistics
1760 Euclid St. NW Suite 306
Washington, DC 20009
(202) 745-0114 fax: (202) 745-0446
[EMAIL PROTECTED]

--

From: Markku J. Saarelainen [EMAIL PROTECTED]
Subject: Read my messages in alt.politics.org.cia - you will be satisfied !
Date: Fri, 28 Jan 2000 21:19:28 GMT



Read my messages in alt.politics.org.cia - you will be satisfied.


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

--

From: "Joseph Ashwood" [EMAIL PROTECTED]
Subject: Re: Mac encryption algorithm?
Date: Fri, 28 Jan 2000 13:35:49 -

 And why is this byte order "wrong" ?  Little Endian and
Big
 Endian are merely two different byte orders, both of which
have
 their advantages and disadvantages.
There are actually algorythms that require a specific
Endianness to be secure. I can't think of which one offhand,
but IIRC an AES candidate was one of these.
Joe



--

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Help needed on peculiar use of cryptography
Date: Fri, 28 Jan 2000 14:58:43 GMT

[EMAIL PROTECTED] (Sgwbutcher) wrote, in part:

a social security number can be encrypted
so that the informational value of the cyphertext can be retained but the
plaintext cannot be recovered?

It is not clear what this wording means. However, a one-way hash
function can allow a social security number to be encrypted so that,
althought the social security number itself cannot be rec

Cryptography-Digest Digest #996

1999-01-29 Thread Digestifier

Cryptography-Digest Digest #996, Volume #8   Fri, 29 Jan 99 09:13:02 EST

Contents:
  Re: what do u think about this algorithm of mine? ("Uta Loeckx")
  Smaller RC6 (handWave)
  Fialka Punch Card Speculation
  Re: Smaller RC6 (Fabrice Noilhan)
  Re: Sanity check on authentication protocol (Paul Onions)
  Re: Random numbers generator and Pentium III (R. Knauer)
  Re: Random numbers generator and Pentium III (R. Knauer)
  Re: Fialka Punch Card Speculation (Frode Weierud)
  Re: Coin Toss Theory (R. Knauer)
  Re: Random numbers from a sound card? (Patrick Juola)
  Re: hardRandNumbGen (Patrick Juola)
  Re: hardRandNumbGen (Patrick Juola)
  Re: Question on key lengths (Patrick Juola)



From: "Uta Loeckx" [EMAIL PROTECTED]
Subject: Re: what do u think about this algorithm of mine?
Date: Fri, 29 Jan 1999 13:07:50 +0100

Klaus Rohde wrote:

 i don't know anything about encryption, but one day i was thinking about
 it and had an idea for an algorithm which, as far as i can see, is
 unbreakable.

 you take byte n of a text stream and XOR it with byte n of the key to
 produce byte n of the cipher text.

 to me this seem's unbreakable, because by applying the right key any
 cipher text can be decoded into literally anything of the same length,
 meaning that unless someone has the key, they can't gain anything out of
 the cipher text.

Read Bruce Schneier's "Applied Cryptography" and you'll see that you haven't been
the first one to come up with this algorithm. It's about the first thing you
encounter when you start with cryptography as I did myself some months ago. Any
other introduction will do, by the way (Beutelspacher: "Moderne Verfahren der
Kryptographie" for German Speaking is quite funny to read).
If I am not mistaken the thing you re-invented is called "One Time Pad". It is, as
you pointed out, unbreakable. But...
...once you use the key twice or more often, it is most easily breakable. Imagine
two ciphertexts of a certain length L in bits, and ONE key with the very same
length. There are 2^L possible keys, 2^L possible plain texts for each cipher text.
Only a small amount of the possible plain texts make sense, that's why only the
same small amount of the possible keys are candidates for decrypting each
ciphertext. You will hardly find more than one key which fits both ciphertexts if
these ciphertext exceed a (un)certain length. This length depends on the structure
of the encrypted data.

Conclusion: One time pads are used. Spies use them. They may have a one time pad of
some million or so byte key length. Somebody at home can read the ciphertext, but
afterwards they have to throw the key pad away. God help them if some of the
ciphertext gets lost and they do not know which byte of the key they have to use.
The problem is, that you have to transmit the key through a secure channel. But,
since the key is as long as the data, you could as well transmit that (provided you
know it at this point of time).

So, the method does not really apply to a lot of situations where encryption is
needed.
For instance, if you simply want to store a file securely on your computer, it does
not help to encrypt it with a one time pad, because you would have to hide the pad.

Andreas



 any thoughts or ideas (or proof that what im saying is nonsense) would be cool.

:-) peter

--
==

Andreas Jaeger
Institut für Geoinformatik, Universität Münster
Robert-Koch-Straße 26/28
D-48149 Münster

Tel.: (0251) 83 - 3 00 11
Fax: (0251) 83 - 3 97 63
mailto:[EMAIL PROTECTED]

==

Andreas Jaeger
Hammer Straße 14
D-48153 Münster

Tel.: (0251) 53 37 78

==



--

From: handWave [EMAIL PROTECTED]
Subject: Smaller RC6
Date: Fri, 29 Jan 1999 04:39:49 -1000

The RC6 candidate for the Advanced Encryption Standard can use small 
parameters for smart cards. RC6-w/r/b can use w=32 bit words, r=4 rounds, 
and b=10 byte keys. It may use cipher block chaining so the small block 
size does not leave it vulnerable to adversaries accumulating a 
dictionary of 4 billion words. After 4 rounds, the mixing is nearly 
ideal. The 80 bit key is good enough for rock and roll.

--

From: [EMAIL PROTECTED] ()
Subject: Fialka Punch Card Speculation
Date: 29 Jan 99 12:45:27 GMT

The post with "Information Pool" (well, really "inforamtionpool") in the
header concerns Joerg Drobick's web site, with information about some
cipher machines from behind the Iron Curtain.

The Fialka is claimed to be a 10-rotor Enigma, with a punched card
performing the function of the plugboard.

It occurs to me that, if the punched card is used to open connections in a
crossbar patch