Cryptography-Digest Digest #806, Volume #8       Mon, 28 Dec 98 17:13:02 EST

Contents:
  Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
  Re: Open source Crypto algorithms in Java (KloroX)
  Re: What is Randomness? (Mok-Kong Shen)
  Re: Highly structured info. (XML) and decryption
  Re: What is Randomness? (Mok-Kong Shen)
  Re: On living with the 56-bit key length restriction
  Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
  Re: On living with the 56-bit key length restriction (Mok-Kong Shen)
  Re: Secure Indicators for the Enigma
  Re: Common Modulus Attack on RSA ("Max")
  Re: RSA-Broken!!! (STL137)
  World's fastest block cipher: Mercy web pages updated (Paul Crowley)
  Re: Microsoft SGC (SSL), CrytoAPI? (Mr. Tines)
  Re: RSA-Broken!!! (John Bailey)
  Re: What is Randomness? ("John Feth")

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 28 Dec 1998 11:23:03 +0100

Michael A. Greenly wrote:

>     Unless I've missed something individuals and criminal organizations
> will be able to protect there privacy with freeware applications like
> PGP.  This means that the real target of the Wassenaar agreement must be
> industry.  If not industry who everyone else gets to use stong crypto?

Personally I slowly come to a conjecture that is inline with your
second but last sentence. What is claimed to be the official purpose 
could well be a hypocrisy. The real target, I'll generalize a bit, 
could be simply the rest of the countries of the world.

M. K. Shen

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

From: [EMAIL PROTECTED] (KloroX)
Crossposted-To: comp.lang.java.programmer,comp.lang.java.security
Subject: Re: Open source Crypto algorithms in Java
Date: Mon, 28 Dec 1998 10:59:55 GMT
Reply-To: [EMAIL PROTECTED] (this is spam bait)

This is a package that would figure well on ftp.replay.com, especially
since straightforward implementations of cryptographic code in Java
are much harder to come by than in C/C++ (most of the Java code are
large and intricate libraries, not worth the effort of dissecting a
few simple classes out of them). Any thought of putting it there?

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What is Randomness?
Date: Mon, 28 Dec 1998 10:29:49 +0100

R. Knauer wrote:
> 

> Then conisder a plaintext that has been compressed by the most
> efficient compression algorithm known. Call that sequence CP for
> "Compressed Plaintext". Now find the minimal algorithm that will
> reproduce it. That algorithm must of necessity be of the same order of
> complexity as the length of CP, since by assumption CP cannot be
> compressed any further.

I think that here is a problem. You said 'the most efficient
compression algoritm known', not 'the most efficient compression
algorithm that can ever exist'. Further, is describing a string
by an algorithm that can produce it a sort of 'compression'?
If yes, I guess that the argurment risks to go around a circle.

My point against theories like that of Chaitin is that one seems
to lift oneself from the ground and talk of matters that in reality 
cannot exist. Such a theory may be consistent and interesting
in 'itself' but can't have any practical value except providing some
'illumination', I am afraid.

M. K. Shen

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

From: <[EMAIL PROTECTED]>
Subject: Re: Highly structured info. (XML) and decryption
Date: Mon, 28 Dec 1998 11:46:15 +0100

On Mon, 28 Dec 1998, Anders W. Tell wrote:

> 
> Harpy-36 wrote:>
> >
> > > Could someone point me to any resources where this issue have been
> > > dealt with/researched or is this already a well known problem in the
> > > "crypt"
> > > community ?
> >
> > It is already well known. Cipher block chaining or cipher feedback modes
> > use an Initialization Vector to alter the first block with a
> > pseudo-random number so that this common header is obfuscated.
> 
> Do you know which modern and widely used algoritms uses this technique ?
> 

All blockciphers - DES, 3DES, IDEA, blowfish, skipjack ...

The key of simple DES is too small for strong crypto.
IDEA is well-known and fast but it is patented.
3DES is slow in software but fast in hardware.
Blowfish uses slow key-shedule but encrypts and decrypts very fast on 32
bit computers.
Skipjack is designed for usage with smartcards.

There are lots of others, but I'd use one of these ciphers.

> 
> > Then
> > subsequent blocks are chained with earlier blocks to carry along this
> > uniqueness. If this technique is not used and Electronic Code Book Mode
> > is used, then your concern is correct: headers would make it easier to
> > detect a correct cryptanalysis.
> 
> The other concern I have is that all pieces of information in a XML message
> is enclosed in tags. Example
> <msg>
>  <value> 1234.57 </value>
> </msg>
> 
> At all positions in a message there will be a well known "structure"
> with start tags followed by end tags.
> 
> Doestt this feature alone make it "significantly" easier to break any
> encrypted message
>

All attacks except brute force (the only cipher of the ones I mentioned
that could be brute-forced is DES) need a huge amount of known plaintext.

Only the tags wouldn't allow to break the cipher, but they make it easier
to decide what is the correct plaintext.

So I'd say: 
Easier: YES
Significantly easier: NO.
 
> Regards
> --
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> /  Financial Toolsmiths AB  /
> /  Anders W. Tell           /
> /_/_/_/_/_/_/_/_/_/_/_/_/_/_/
> 
> 
> 
> 

Enterrottacher Andreas

[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: What is Randomness?
Date: Mon, 28 Dec 1998 10:38:22 +0100

John Feth wrote:

> 
> A useful and much less esoteric (read less intimidating) approach is to
> create an Allan Variance plot of the set of numbers under consideration.
> The Allan Variance is found for a set of n numbers (say the first thousand
> digits of pi) simply by calculating the variance of all the individual
> digits, the variance of the averages of the sums of contiguous pairs, the
> variance of the averages of the sums of contiguous triplets,...and so on
> all the way up to the variance of the averages of the first n/2 digits and
> the last n/2 digits.

Could you give a literature reference on 'Allan Variance'?

M. K. Shen

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

From: <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 28 Dec 1998 11:33:22 +0100

On Mon, 28 Dec 1998, Mok-Kong Shen wrote:

> [EMAIL PROTECTED] wrote:
> > 
> > Mok-Kong Shen wrote:
> > > [EMAIL PROTECTED] wrote:
> > > > I don't think so. The main target of this law are neither countries nor
> > > > well organised criminals. This law allows to control telecommunication:
> > > > People have to use standard software if they want to stay in contact
> > > > with others. This software is protected by different copyrights so it
> > > > can't be changed without breaking laws. By keeping the huge companies
> > > > from exporting strong crypto it is possible to keep people from
> > > > encrypting the normal correspondence and to detect encrypted data
> > > > streams.
> > >
> > > Those who have no secrets to hide will not use cryptos. Hence 'normal'
> > > correspondences do not contain stuffs interesting for the intercepting
> > > guys.
> > 
> > 'Normal' doesn't mean 'small talk'. It means business correspondence,
> > data from industry and science etc.
> > 
> > One of the missions of NSA is to do industrial espionage - and other
> > agencies may not be different.
> 
> Coming back to you previous sentence 'The main target of this law are 
> neither countries nor well organised criminals', I'll say that the
> second part is true. For criminals can smuggle cryptos and then
> duplicate these into unlimited copies for use. I am not sure of
> the first part. The law is certainly disadvantageous for the
> crypto-technically underdeveloped countries. So indirectly their
> national economy may be negatively influenced (in diverse ways),
> in other words to the advantage of countries introducing the law.
>

Exactly.
 
> > 
> > > Those who do want to hide something certainly can afford to
> > > take some inconvenience of first putting the messages through some
> > > 'private' cryptos before sending them on the public lines. As
> > > I mentioned elsewhere, the 'real' intention of the Wassenaar agreement
> > > appears not to be crystaline clear. A remark to your last point:
> > > If encryption is not generally forbidden, detecting encrypted data
> > > streams may not mean very much if decryption is not feasible.
> > >
> > 
> > And if strong crypto is forbidden?
> 
> It depends on your definition of strong crypto. It is my opinion
> that 56-bit algorithms can be developed that are strong. And these
> are not subject to any export restriction.
> 
>

We should do everything to meet this goal.
 
> > > If you have really top secrets to be transmitted in time, I am
> > > not sure that money definitely counts very much for you. Even if
> > > you have only one single line, you can send the pieces at different
> > > time points
> > 
> > This doesn't help at all if the line is controlled by the attacker.
> 
> It depends on how much control the attacker has. If he can e.g.
> cut off the line, then of course you are right. As long as he
> plays a passive role and can't decrypt the messages, why care?

This is why strong encryption and/or steganography is so important.

> 
> M. K. Shen
> 
> 


Andreas Enterrottacher

[EMAIL PROTECTED]
[EMAIL PROTECTED]


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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 28 Dec 1998 10:57:52 +0100

wtshaw wrote:
> 
> So many will just say encrypt it all, or try to have no security at all.
> Needless to say, those that do err or the side of security are more apt to
> have more security; it is up to us to see that it is available if wanted,
> even on someones whim.  Now, encrypting everything is not especially
> useful to those who want to filter.  Meanwhile, the mere use of marginal
> encryption can throw a monkey wrench is such a process, like reversing the
> characters in this paragraph:

In the (probably unfortunately unrealistic) case that everybody 
encrypts his communications selecting one of a (hopefully available) 
large number of different algorithms that are within the restiction 
set up by Wassenaar, I suppose that the authorities would have such 
a huge amount of materials to process and have to try all the possible 
algorithms that a particular user may have used that their chance 
of finding something interesting would be negligible.

M. K. Shen

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: On living with the 56-bit key length restriction
Date: Mon, 28 Dec 1998 11:15:17 +0100

[EMAIL PROTECTED] wrote:
> 
> Mok-Kong Shen wrote:
> > [EMAIL PROTECTED] wrote:
> > > I don't think so. The main target of this law are neither countries nor
> > > well organised criminals. This law allows to control telecommunication:
> > > People have to use standard software if they want to stay in contact
> > > with others. This software is protected by different copyrights so it
> > > can't be changed without breaking laws. By keeping the huge companies
> > > from exporting strong crypto it is possible to keep people from
> > > encrypting the normal correspondence and to detect encrypted data
> > > streams.
> >
> > Those who have no secrets to hide will not use cryptos. Hence 'normal'
> > correspondences do not contain stuffs interesting for the intercepting
> > guys.
> 
> 'Normal' doesn't mean 'small talk'. It means business correspondence,
> data from industry and science etc.
> 
> One of the missions of NSA is to do industrial espionage - and other
> agencies may not be different.

Coming back to you previous sentence 'The main target of this law are 
neither countries nor well organised criminals', I'll say that the
second part is true. For criminals can smuggle cryptos and then
duplicate these into unlimited copies for use. I am not sure of
the first part. The law is certainly disadvantageous for the
crypto-technically underdeveloped countries. So indirectly their
national economy may be negatively influenced (in diverse ways),
in other words to the advantage of countries introducing the law.

> 
> > Those who do want to hide something certainly can afford to
> > take some inconvenience of first putting the messages through some
> > 'private' cryptos before sending them on the public lines. As
> > I mentioned elsewhere, the 'real' intention of the Wassenaar agreement
> > appears not to be crystaline clear. A remark to your last point:
> > If encryption is not generally forbidden, detecting encrypted data
> > streams may not mean very much if decryption is not feasible.
> >
> 
> And if strong crypto is forbidden?

It depends on your definition of strong crypto. It is my opinion
that 56-bit algorithms can be developed that are strong. And these
are not subject to any export restriction.


> > If you have really top secrets to be transmitted in time, I am
> > not sure that money definitely counts very much for you. Even if
> > you have only one single line, you can send the pieces at different
> > time points
> 
> This doesn't help at all if the line is controlled by the attacker.

It depends on how much control the attacker has. If he can e.g.
cut off the line, then of course you are right. As long as he
plays a passive role and can't decrypt the messages, why care?

M. K. Shen

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

From: [EMAIL PROTECTED] ()
Subject: Re: Secure Indicators for the Enigma
Date: 28 Dec 98 13:25:25 GMT

[EMAIL PROTECTED] wrote:
: 4) Set the Enigma to the second three letters.

: 5) Encipher the 20-letter "plugboard key".

Actually, if one does step 5 before step 4, one has more possible settings
for one's Enigma. Also, since we are dealing with two independent
settings, one need not stagger the two enciphered wheel positions before
using bigram tables.

If one wants to use an Uhr box, it is necessary to connect all 10 plugs,
so the procedure can be changed as follows: have a 30-letter plugboard
key; if one still does not have 20 letters left among the non-duplicates,
then go through the remaining letters in order (first the odd one, if any,
then each duplicate from the beginnning) and for each duplicate letter,
take the next vacant socket after the one it indicates.

John Savard

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

From: "Max" <[EMAIL PROTECTED]>
Subject: Re: Common Modulus Attack on RSA
Date: Mon, 28 Dec 1998 09:08:19 -0700

Ian Goldberg wrote in message <760dc2$o43$[EMAIL PROTECTED]>...
>In article <U$ps9G7L#[EMAIL PROTECTED]>,
>Max <[EMAIL PROTECTED]> wrote:
>>I don't quite understand the math involved here, and was wondering if
>>someone could help me.
>>
>>Let's say I'm part of a network that was naive enough to issue a common
>>modulus to all of its users.  How could a malicious user, knowing his own
>>encryption/decryption key pair (e,d) factor the modulus n in an efficient
>>manner such that he could then compute the decryption (private) keys for
all
>>other users of the network?
>>


<snip>

>  o Calculate d such that de = 1 mod phi(n)  [Here's where knowing the
>    factorization of n is used; phi(n)=(p-1)(q-1) if n=pq; but note that
>    all we _really_ need is phi(n).]; i.e. de-1 = k*phi(n) for some k.
>
>Well, you know _your_ d and e, so you can calculate de-1 = k*phi(n), and
>learn k*phi(n) (but you don't yet know what k is).

OK, but what if all the user knows is n (the modulus), not phi(n) [which is
(p-1)(q-1)]?  What I'm really wondering is how someone factors n, given only
an e,d pair and the modulus n.






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

From: [EMAIL PROTECTED] (STL137)
Subject: Re: RSA-Broken!!!
Date: 28 Dec 1998 20:28:49 GMT

Uh HUH. And you've also done the following, I take it:
Solved the Riemann conjecture, and did it in an elementary proof.
Solved Goldbach's conjectures, again with elementary proofs.
Found a way to unify the four fundamental forces of nature.
And so on.
========
[EMAIL PROTECTED]  ~  http://137.tsx.org  ~  http://quote.cjb.net
I block all unapproved E-mail. If you wish to talk to me, post to
alt.test.9 with the subject "Moo" and your E-mail address in the
body. I will allow you as soon as I sign on next.

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

From: Paul Crowley <[EMAIL PROTECTED]>
Subject: World's fastest block cipher: Mercy web pages updated
Date: 28 Dec 1998 19:47:20 -0000

Mercy is a block cipher for 4096 bit blocks, designed for the needs of
disk sector encryption.  At 9.4 cycles/byte, it's faster than any
other block cipher I know of; this is possible because of the large
block size, and the primary goal of its design is to stimulate
discussion of block ciphers with large blocks.  Mercy is AFAIK
unencumbered by patents, and the sample source is public domain.

After a longish hiatus, the Mercy web pages have undergone a serious
update; the algorithm is now up to revision 4, and an eight-page
Postscript document describing the cipher and explaining some of the
decisions is available there.

If you visit, please let me know what you think!

http://www.hedonism.demon.co.uk/paul/mercy/
-- 
  __
\/ o\ [EMAIL PROTECTED]  http://www.hedonism.demon.co.uk/paul/ \ /
/\__/ Paul Crowley            Upgrade your legacy NT machines to Linux /~\

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

From: Mr. Tines <[EMAIL PROTECTED]>
Subject: Re: Microsoft SGC (SSL), CrytoAPI?
Date: 27 Dec 1998 18:55 +0000

###

On Sat, 26 Dec 1998 20:14:31 -0600, in <764568$heh$[EMAIL PROTECTED]>
          "R H Braddam" <[EMAIL PROTECTED]> wrote.....

> denis bider wrote in message ...
> >Has anyone had any experiences with the security of
> Microsoft's SGC
> >implementation? (Or, which is the same thing,
> Microsoft's SSL implementation
> >without the export limitations) Or about Microsoft's
> CryptoAPI?
[snip]
> The only experience I have with it is from compiling
> the ENUMALGS example in the SDK samples and running it.
> My system is supposed to be upgraded to 128 bit
> security, but Enumalgs.exe reports only 40-bit RC2 and
> RC4. No other encryption algorithms at any strength.

On WinNT4, at least, the little documented
SystemFunction032() offers unlimited strength RC4,
even on exported systems (as reported in this newsgroup
about 18 months ago, under a title like "Microsoft
exports strong crypto").  I've tested it against an
implementation of my own, and it matched byte for byte.

-- PGPfingerprint: BC01 5527 B493 7C9B  3C54 D1B7 248C 08BC --
 _______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_  __(_)__  ___ ___     {69c10bcfbca894a5bf8d208d001b829d4d0}
 / / / / _ \/ -_|_-<      www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\[EMAIL PROTECTED]      PGP key on page

### end pegwit v8 signed text
d9437bdbbfa6114f16cba2cacb48dfc8b9ab66d97dfa32ca2354350f15fd
8b48e086f63cac4606f5d19fe9b552a22c8b7f9eadb95a35fac2af3ee47a


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

From: [EMAIL PROTECTED] (John Bailey)
Subject: Re: RSA-Broken!!!
Date: Mon, 28 Dec 1998 20:18:22 GMT

On Mon, 28 Dec 1998 12:56:11 GMT, [EMAIL PROTECTED] wrote:
>For more details please refer to
>www.online.de/home/aernst/rsa.html
Its more like
http://www.online.de/home/aernst/RSA.html
John

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

From: "John Feth" <[EMAIL PROTECTED]>
Subject: Re: What is Randomness?
Date: 28 Dec 1998 17:17:33 GMT

Here is a starter list:

D.B. Sullivan, D.W. Allan, D.A. Howe. and F.L. Walls, Editors,
"Characterization of Clocks and Oscillators" NIST Tech Note 1337, March
1990 is a great compendium of a large number of articles on the subject
available by mail from NIST, Time and Frequency Division, Boulder Colorado.

D.W. Allan "The Measurement of Frequency and Frequency Stability of
Precision Oscillators" NBS Tech Note 669, July 1975 available by mail from
NIST, Time and Frequency Division, Boulder Colorado.

Bear in mind that clock and oscillator researchers can't measure frequency
very well (!), but they can measure phase quite well.  So after presenting
the basic Allan Variance algorithm, the algorithms they use to calculate
the Allan Variance for clock characterization take phase data and
differentiate it to get the frequency, to produce the Allan Variance on the
frequency.  This is why they make a point of calling the data "phase" or
"frequency".  Cryptographic data sets (and gyro data--see below) are
equivalent to frequency data and the Allan Variance is run directly on the
data without the differentiation step.  D. A. Howe is still at NIST and
very helpful if you have further questions.

Lawrence Ng "On the Application of Allan Variance Method of Ring Laser Gyro
Performance Characterization" October 1993 UCRL-ID-115695 reviews the Allan
Variance basics and contains an excellent algorithm for the recursive
calculation of the Allan Variance from "frequency" (or cryptographic) data.
 The work was done at Lawrence Livermore Labs (California) and is available
from National Technical Information Service, US Dept of Commerce, 5285 Port
Royal Road, Springfield, VA 22161

 Hope this keeps you interested,

John Feth
 



Mok-Kong Shen <[EMAIL PROTECTED]> wrote in article
<[EMAIL PROTECTED]>...
> John Feth wrote:
> 
> > 
> > A useful and much less esoteric (read less intimidating) approach is to
> > create an Allan Variance plot of the set of numbers under
consideration.
> > The Allan Variance is found for a set of n numbers (say the first
thousand
> > digits of pi) simply by calculating the variance of all the individual
> > digits, the variance of the averages of the sums of contiguous pairs,
the
> > variance of the averages of the sums of contiguous triplets,...and so
on
> > all the way up to the variance of the averages of the first n/2 digits
and
> > the last n/2 digits.
> 
> Could you give a literature reference on 'Allan Variance'?
> 
> M. K. Shen
> 

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


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and sci.crypt) via:

    Internet: [EMAIL PROTECTED]

End of Cryptography-Digest Digest
******************************

Reply via email to