Cryptography-Digest Digest #362, Volume #12       Sat, 5 Aug 00 15:13:00 EDT

Contents:
  On general encryption schemes (Mok-Kong Shen)
  Re: just saw a pre-release copy of Schneier's new book on ebay (Bruce Schneier)
  David Scott's website (SCOTT19U.ZIP_GUY)
  Re: Good pointers on MDS ("Peter L. Montgomery")
  Re: Mathématics ("Kurt Fleißig")
  Re: Good pointers on MDS (tomstd)
  Re: counter as IV? (David Hopwood)
  Re: OTP using BBS generator? (David Hopwood)
  Re: IV for arfour ("Andreas Sewe")
  Re: Secure Operating Systems (Mok-Kong Shen)
  Re: Secure Operating Systems ([EMAIL PROTECTED])
  Re: Plausible Word Generation via Trigram Statistics (Mark Wooding)
  Re: New William Friedman Crypto Patent (filed in 1933) (Bill Unruh)
  Re: New William Friedman Crypto Patent (filed in 1933) (John Savard)

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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: On general encryption schemes
Date: Sat, 05 Aug 2000 16:41:06 +0200


A ciphertext C is a transform of the plaintext according to a key 
and hence has the general form C=f(K,P), where f is an arbitrary 
invertible function and P is the 'entire' plaintext. This clearly
shows that both stream encryption, operating on single bits,
and block cipher, operating on groups of bits, are 'very' special
cases of a general encryption. A block cipher of size n provides
diffusion and confusion within the boundary of the n bits that
it works on. It does not utilize the 'context' information of
the rest of plaintext and thus could be regarded as wasting the
available 'resources'. Some remedy of this has in fact been found 
in block-chaning, where the blocks are made to influence one 
another in some way. But this is at best sort of 'after thought' 
and apprently could not be the optimal way of achieving the goal 
of encryption processing. (The tendency of developing larger
block algorithms could also be viewed in this light.)

We see therefore that there can be essential advantages of 
treating the entire plaintext in a 'holistic' manner rather than 
always confining our view through a small window of n bits. On 
the other hand, any work done on a big real-world object is 
invariably composed of work done on its parts. So 'regional' 
operations provided by block algorithms are indeed a necessity. 
What is desirable 'in addition' are however global operations 
that cause the blocks to interact in ways that can materially 
contribute to the complexity that the opponent has to face.

I don't have currently a good proposal to this issue but like
to sketch several possibilites that I can see besides the already
existing block chaining mentioned above. One possiblity is pseudo-
random permutation of the computer words constituting the entire 
plaintext. One can namely permute, do block encryption, permute, 
... etc. Another possibility is to look the whole plaintext as a 
single block and apply block encryption techniques to it. One can, 
for example, divide the plaintext into two halves and apply the
Feistel method on these. A third possibility is to effect
substitution on units larger than the size of the block algorithm
used. One practical way of doing this is through a Hill cipher
with a sufficiently large matrix.

In a certain sense, dynamically varying the key of the block
algorithm or its parameters or varying the block algorithm itself 
(or the component algorithms in case of multiple encryption) could 
also be considered to be global operations that are desirable.

My humble knowledge doesn't allow me presently to think of more 
and eventually better possibilities. Your suggestions, comments
and critiques would be highly appreciated.

M. K. Shen
==============================
http://home.t-online.de/home/mok-kong.shen

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

From: Bruce Schneier <[EMAIL PROTECTED]>
Subject: Re: just saw a pre-release copy of Schneier's new book on ebay
Date: Sat, 05 Aug 2000 09:33:49 -0500

On Sat, 05 Aug 2000 13:09:22 GMT, [EMAIL PROTECTED]
(John Savard) wrote:
>On Sat, 05 Aug 2000 08:19:49 GMT, [EMAIL PROTECTED] (Ben Liberman)
>wrote, in part:
>
>>I'm not a collector myself but, for anyone interested, I was wandering
>>eBay and came across:
>
>>"Signed Pre-Release Copy of Bruce Schneier's New Book: Secrets and Lies"
>
>>http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=401272439
>
>Will Bruce himself be the most interested...or, even if that copy is
>"pre-release", has the book itself already been released?

The full title is SECRETS AND LIES: DIGITAL SECURITY IN A NETWORKED
WORLD, and the book homepage is:

http://www.counterpane.com/sandl.html

The book has not been published yet.  It should be available in
bookstores by the end of the month.

SECRETS AND LIES discusses computer security, and the issues
surrounding computer security.  It explains, in an accessible style,
how different security technologies work and how they fail.  It
discusses the process of security: what the threats are, who the
attackers are, and how to live in the their world. 

You can buy the title from Amazon at a 30% discount at:

http://www.amazon.com/exec/obidos/ASIN/0471253111/counterpane/002-7793097-4376006

The eBay listing isn't authorized, but it didn't happen without my
knowledge.  Lydy told me that she would sell her copy on eBay, and I
didn't tell her not to.  There were only a couple hundred galley
copies printed, and they primarily went to the press...so maybe it is
a collecters' item.

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

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

From: [EMAIL PROTECTED] (SCOTT19U.ZIP_GUY)
Subject: David Scott's website
Date: 5 Aug 2000 14:48:13 GMT

 As many of you know my hobbies are encryption and compression.
I have been to busy to give justice to each. But I will have more
time soon. 
 Also many people have been unhappy that the site does not allow
browers with "JavaScript or Active-X". I have removed all such
restrictions for the time being. There are still pages that warn
the user not to go to main page but I will eventually change all
such pages as I update them



David A. Scott
-- 
SCOTT19U.ZIP NOW AVAILABLE WORLD WIDE
        http://www.jim.com/jamesd/Kong/scott19u.zip
Scott famous encryption website **now all allowed**
        http://members.xoom.com/ecil/index.htm
Scott rejected paper for the ACM
        http://members.xoom.com/ecil/dspaper.htm
Scott famous Compression Page
        http://members.xoom.com/ecil/compress.htm
**NOTE EMAIL address is for SPAMERS***
I leave you with this final thought from President Bill Clinton:
   "The road to tyranny, we must never forget, begins with the destruction 
of the truth." 

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

From: "Peter L. Montgomery" <[EMAIL PROTECTED]>
Subject: Re: Good pointers on MDS
Date: Sat, 5 Aug 2000 15:19:54 GMT

In article <[EMAIL PROTECTED]> 
[EMAIL PROTECTED] (Mack) writes:
>Does anyone have good pointers on MDS codes?

>Off line references are ok but I would prefer
>some web links.

    Do you mean MD5?  If so, search for `md5 rfc 1321' at www.yahoo.com .
If not, tell us what the acronym `MDS' denotes.
-- 
E = m c^2.  Einstein = Man of the Century.  Why the squaring?

        [EMAIL PROTECTED]    Home: San Rafael, California
        Microsoft Research and CWI

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

From: "Kurt Fleißig" <[EMAIL PROTECTED]>
Subject: Re: Mathématics
Date: Sat, 5 Aug 2000 17:09:00 +0200


Ioshua ha scritto nel messaggio <[EMAIL PROTECTED]>...
>Does someone know MAPLE V.4 PRO?
In order to..... ?
BR
K
>
>------
>User of http://www.foorum.com/. The best tools for usenet searching.



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

Subject: Re: Good pointers on MDS
From: tomstd <[EMAIL PROTECTED]>
Date: Sat, 05 Aug 2000 08:35:45 -0700

"Peter L. Montgomery" <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>
>[EMAIL PROTECTED] (Mack) writes:
>>Does anyone have good pointers on MDS codes?
>
>>Off line references are ok but I would prefer
>>some web links.
>
>    Do you mean MD5?  If so, search for `md5 rfc 1321' at
www.yahoo.com .
>If not, tell us what the acronym `MDS' denotes.

MDS = Maximal Distance Separatable.  It's a form of square
multipermutation used to promote large diffusion.

Tom


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

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com


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

Date: Sat, 05 Aug 2000 17:47:44 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: counter as IV?

=====BEGIN PGP SIGNED MESSAGE=====

"David A. Wagner" wrote:
> Bodo Moeller <[EMAIL PROTECTED]> wrote:
> > David A. Wagner <[EMAIL PROTECTED]>:
> > > Using a truly random IV eliminates this vulnerability.  That's why I
> > > recommend to use an unpredictable, random IV, and not, e.g., a counter.
> >
> > Does it really have to be a *truly* random, *unpredictable* IV?
> > What about applying a publicly known PRF to counter values?
> 
> Sorry for the imprecision.  You are quite right to suggest that using
> a PRF is just as good.  There is no need for IVs to be truly random;
> unpredictability suffices.  I apologize for that error.

They also don't need to be unpredictable, if I understand correctly;
just uniformly distributed. For example, with the method using a PRF
applied to a counter, it is not strictly necessary to keep the PRF key
secret (as long as the key was chosen at random and not reused with the
same counter value, and the plaintext is not dependent on the IVs).

- -- 
David Hopwood <[EMAIL PROTECTED]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv

iQEVAwUBOYxFCTkCAxeYt5gVAQH8xwf/QrrbuMHiVG4XshCiwRmgFowkAW16KK4D
isLYj3aMDht7a1XTo9IdGHTtXoOt2KC7jfMJk/rrrm58w1loPEHSuJuTNxITJc56
UJr4eVbhsEJ5U0OgA66bFfGfF7O80T7UOdnPCfg0Cl916a36qT0gjBgwXMAtZDLl
WKurjGkLYjqQPBuGvyJsV63YOXbNkukL/xHTdsHJVsd6B7Vxs2J94ZZXiK23uAC5
y4Ay8WBNXkYlOvVumBl32jTSe+GLstvJlqNVtwhfe2i1Gznbf+51MKg649WnA619
M4C8zTALujC1hY4q8IOeJ1cRZxTsWTFoxLiJPT9Rcv6LlvoH4LGVfQ==
=mbpr
=====END PGP SIGNATURE=====



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

Date: Sat, 05 Aug 2000 18:38:36 +0100
From: David Hopwood <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: OTP using BBS generator?

=====BEGIN PGP SIGNED MESSAGE=====

Joseph Ashwood wrote:
> I know I'm arriving rather late to the party but, while Mr Ritter and I have
> been on differing sides of discussions before, I agree with him completely
> in this case. What he has suggested is to verify the lack of a short cycle,
> through a relatively cheap mechanism (certainly cheaper than the compromised
> security that could result is that check would have been failed).

It's not particularly cheap in terms of the speed of parameter generation,
and it has been proven that short cycles happen with negligable probability,
if the parameter sizes are such that factoring is hard.

The probability of weakness is not changed significantly by applying the
constraints that Ritter thinks are necessary; as has been pointed out
repeatedly, his arguments are based on a misunderstanding of the BBS
security proofs.

> I find this to be solid reasoning, and something that should be done by
> anyone making use of BBS in this fashion.

It really doesn't provide any significant advantage - if checking for short
cycles were actually needed for BBS, that would cast doubt on the security
of every IFP-based cryptosystem, including RSA, Rabin, etc.

- -- 
David Hopwood <[EMAIL PROTECTED]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


=====BEGIN PGP SIGNATURE=====
Version: 2.6.3i
Charset: noconv

iQEVAwUBOYxQ5jkCAxeYt5gVAQGerAgAr0jXT3fyZFVkFZVdCoXu2AR4Ur+BdIzt
0F1gYbwODTSpFjeovdJTKwT18blRYwiHZyZL+z6H8ob/XYJS0OH67szO8IJbWzBL
Ulchhw60m5wExA617AQ6JOwheKTkfxJsUErhY62b3ojFWOmviI/Z6M2HpQ3gz0bP
yTb1IOoGNuikKcqt6xCqG51vswGtp5FX+Lpv34fW8AApD/Um+GR4jrbYAyHUgB8z
18g0Dg67TlLMDdQsxqy50VBzgWF/tJEyz4YoWj142Dzeh8GQhoZd/Aoygar4cJ2x
an3agDB4WQUFjGQCSJ0xBAuONP7U6x7mdAMZqBnY1EOEcynmypUDwg==
=AqMi
=====END PGP SIGNATURE=====


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

From: "Andreas Sewe" <[EMAIL PROTECTED]>
Subject: Re: IV for arfour
Date: Sat, 5 Aug 2000 18:37:31 +0200


"Guy Macon" wrote:

> Andreas Sewe wrote:

> >Perhaps you are right, concerning chosen-key-attacks,

> Could you define "Chosen Key Attack" for me?

Again pseudo-quoting from "Applied Cryptography", chapter 1.1:

"Chosen-key-attack: This term does not mean, that the cryptanalyst is
able to choose the key itself freely; it means instead that certain facts
about the relations between different keys are known.
This kind of attack is uncommon and not of importance in real life.
(Described in chapter 12.4)"

Well, concerning IVs this kind of attack can be imho important.

Andreas Sewe



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

From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: Secure Operating Systems
Date: Sat, 05 Aug 2000 19:05:28 +0200



[EMAIL PROTECTED] wrote:
> 
> I am just wondering why has someone not developed a secure OS which is
> built from the ground up using Crypto for acces control, file handling,
> Porcess security and Intrusion detection..
> 
> I am aware of the efforts of free BSD and Open BSD in adding security
> to Open Unix....but I think something need to be built from the ground
> up rather than an addon

I am not sure that my answer is correct but I venture to give one:
The making of OS is by itself extremely complicated and difficult
to get correct and efficient so that it can be more economical to 
separate out the crypto issue. An OS is often designed with a 
layered approach. Crypto could then be an outer layer. At the time 
of design of UNIX, intrusion detection wasn't yet a word in the
vocabulary of CS, I suppose. To give a (certainly far-fetched) 
analogy about the point of economy: A machine part can be made of 
normal steel and then painted to protect it against corrosion. It 
can also be made of corrosion-free steel. The latter approach is 
generally more expensive, however.

M. K. Shen

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

From: [EMAIL PROTECTED]
Subject: Re: Secure Operating Systems
Date: Sat, 05 Aug 2000 17:55:46 GMT

Mok-Kong Shen <[EMAIL PROTECTED]> wrote:
[...]
> layered approach. Crypto could then be an outer layer. At the time 
> of design of UNIX, intrusion detection wasn't yet a word in the
> vocabulary of CS, I suppose. To give a (certainly far-fetched) 
[...]

When Unix was written, the world was a whole different place. It was
normal for most places to simply leave the administrative account
logged in on the console all day. (Because any console user was
authorised to use it). Offices in the building didn't generally have
locks on the doors, and the standard login mechanism provided abundant
security against networked intrusion. (After all, there were no
unfriendly hosts, and networks were primarily dial-up connections)
Indeed, crypt(3) itself was impervious to exhaustive search, since a
typical large, timesharing system could manage just over a single key
check per second.

The real answer though, is probably that the average user doesn't need
or want what most people are talking about when you say secure
operating system. It doesn't even make sense on personal
computers. For example, Unix based systems hold Orange Book Ratings as
high as B3, but the market for them is very limited.

-- 
Matt Gauthier <[EMAIL PROTECTED]>

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

From: [EMAIL PROTECTED] (Mark Wooding)
Subject: Re: Plausible Word Generation via Trigram Statistics
Date: 5 Aug 2000 16:28:23 GMT

Kurt Shoens <[EMAIL PROTECTED]> wrote:

> As you would expect, the program favors certain words.  I've dealt with
> this, but for reasonable length words, getting the rarity of the words
> generated below about 1 out of 10 billion (or about 33 bits worth)
> is difficult.  For the purposes of password generation, compare this
> to the typical method of choosing 8 random characters from A-Z, a-z, 0-9
> which gives you about 47 bits worth.  For even better security, consider
> Diceware (http://www.diceware.com).

Indeed.  The reason for the difference in entropy is precisely because
you're modelling English words.  They're more redundant than the random
strings you describe.  (And they don't contain digits very often,
either.)  On the other hand, I'd say that they're *much* easier to
remember, for the same entropy content.

I've just bashed together something along the same lines (a simple
Markov model constructed by reading a word list).  Anyone interested can
download my hack from http://www.excessus.demon.co.uk/crypto/wgen.c; I'm
doing a proper version at the moment which I'll add to Catacomb.

Interestingly, but not particularly surprisingly, the entropy of a word
is not directly correlated to its length.  I've just noticed that the
single-letter word `o' has occurred in one of my outputs, at a
probability of 2^{-17}; however, the word `phy' has only probability
2^{-11}.

> Given these limitations, I hope the interest in plausible word
> generation is for some other purpose.

I'm not sure that word generation is such a bad idea.  I'd recommend a
list of words of about 8 or 9 characters as a passphrase, because at
that length they seem to have about 20 bits of entropy each while still
being fairly sensible.

The quality of the fake words depends *very* strongly on the size of
your word list.  If I use my large list, I tend to get mostly poor
results.  Using a much smaller list of common words gives much better
fakes.

-- [mdw]

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

From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: 5 Aug 2000 18:15:21 GMT

In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John Savard) 
writes:

I thought that the US patent law had recently been ammended to makeing a
patent valid for 20 years after filing, not the old 17 years after
issue. Is this correct? This would make this patent outdated before it
was issued.

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

From: [EMAIL PROTECTED] (John Savard)
Subject: Re: New William Friedman Crypto Patent (filed in 1933)
Date: Sat, 05 Aug 2000 19:05:55 GMT

On 5 Aug 2000 18:15:21 GMT, [EMAIL PROTECTED] (Bill Unruh) wrote,
in part:
>In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (John 
>Savard) writes:

>I thought that the US patent law had recently been ammended to makeing a
>patent valid for 20 years after filing, not the old 17 years after
>issue. Is this correct? This would make this patent outdated before it
>was issued.

That's correct, but probably the amendment also stated 'whichever is
greater' or something like that.

John Savard (teneerf <-)
http://home.ecn.ab.ca/~jsavard/crypto.htm

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


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