Cryptography-Digest Digest #58, Volume #11 Sun, 6 Feb 00 13:13:01 EST
Contents:
Re: How to annoy the NSA & break almost any code (Dan Day)
Re: NIST, AES at RSA conference ("Douglas A. Gwyn")
Re: Does the NSA have ALL Possible PGP keys? (Guy Macon)
Re: NIST, AES at RSA conference ("Rick Braddam")
Re: NIST, AES at RSA conference (Paul Crowley)
Re: Court cases on DVD hacking is a problem for all of us (Paul Crowley)
Re: Merkle hash tree patent expired (Paul Crowley)
Re: Random-Width Transposition Tables? (John Savard)
Re: Merkle hash tree patent expired (John Savard)
NSA opens up to US News (Dave Hazelwood)
Scaleable Key Permutation Feature to be Added to CipherText ("C. Prichard")
permission to do crypto research ("Roger Schlafly")
Re: RE ("C. Prichard")
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Dan Day)
Subject: Re: How to annoy the NSA & break almost any code
Date: Sun, 06 Feb 2000 08:13:13 GMT
On Mon, 31 Jan 2000 19:24:19 -0500, "A [Temporary] Dog"
<[EMAIL PROTECTED]> wrote:
>>You can probably annoy the NSA by spreading
>>this news.
>
>Yea, but you can annoy them more by ringing the doorbell and running
>away before they answer.
Yeah, but the snipers would get you before you could run far.
> The NSA hates that.
See above.
--
"How strangely will the Tools of a Tyrant pervert the
plain Meaning of Words!"
--Samuel Adams (1722-1803), letter to John Pitts, January 21, 1776
------------------------------
From: "Douglas A. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 06 Feb 2000 08:25:23 GMT
Terry Ritter wrote:
> ... I think the obvious measure of strength is the time and
> effort required to take ciphertext to plaintext.
If you mean, for the intended recipient who possesses the key,
then that's not an accuracte measure of resistance to enemy
cryptanalysis. If you mean, for the enemy cryptanalyst, that
depends on the cryptanalyst's available intercepts and
ancillary information (including probable plaintext), his
cleverness, skill, and luck; presumably to be a useful measure
it would have to be the *minimum* effort required under some
controlled conditions, but that is not usually known. If you
mean, for the cryptanalyst using the best generally known
attacks, that reminds me of the joke about the fellow who was
searching the curb near a streetlight at night for his car
keys, which he had dropped down the block (but the light was
better near the streetlight) -- or the exhaust emissions
standards for perfectly innocuous compounds that we happen to
have good tests for.
------------------------------
From: [EMAIL PROTECTED] (Guy Macon)
Subject: Re: Does the NSA have ALL Possible PGP keys?
Date: 06 Feb 2000 03:26:04 EST
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dan Day) wrote:
>
>On 02 Feb 2000 09:19:28 EST, [EMAIL PROTECTED] (Guy Macon) wrote:
>>Clearly I can do the same with the number that I make
>>out of the sum of all PGP keys. Let's call it "PBN"
>>(Pretty Big Number). The universe is too small to
>>write down PBN in binary, decimal, or hex, but you
>>can write down PBN in base PBN with ease. it's "10".
>
>And what do you do when someone comes along and
>asks, "what number base was that, again?"
Even worse is the job of making a font with the number
of characters = PBN!
(just in case anyone missed the point, yes I am joking
and no, nobody here incuding me thinks that this is
a useful method. It's just a nerdly joke. )
------------------------------
From: "Rick Braddam" <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: Sun, 6 Feb 2000 02:47:11 -0600
Joseph Ashwood <[EMAIL PROTECTED]> wrote in message
news:eZXhEK3b$GA.315@cpmsnbbsa02...
[replying to David Wagner's post of 1/4/00 @ 6:27pm]
> > Yes, sure, but Terry Ritter claimed that multiple ciphering is
> > strictly *stronger* (i.e., >, not just >=). Such a claim is, as far
> > as I can see so far, unsupported.
>
> Actually the statement that it is strictly stronger can be
> easily contradicted, using XOR (eXclusive-OR), where
> regardless of the keys chosen multiple encipherment is
> strictly equivalent to a single encipherment with the XOR of
> the keys.
> Joe
In his post on 1/30/00 @ 8:01pm Terry said:
It is also true that we cannot express a strength for the use of
multiple ciphers in sequence. But we can convince ourselves of
several things, including: a) since we can use any cipher we want in
the sequence, we can use the one we think is strongest, and the result
will be at least that strong; b) if we use three "thought strong"
ciphers, each of the individual ciphers will be protected from
known-plaintext and defined-plaintext attacks, which does make the
ciphers more resistant in the sense that it limits what the opponents
can possibly do.
Then on 1/31/00 @ 5:01am he posted:
But it is also correct that multiple ciphering is provably strong*er*
in the sense of not allowing known-plaintext and defined-plaintext
attacks on individual ciphers. Partitioning plaintext so that it can
be protected by different ciphers is also provably *less* risky in the
sense that breaking one cipher exposes only that partition and not all
plaintext. These are provable advantages which disappear only when we
assume that breaking multiple ciphers has exactly the same cost as
breaking one.
To which David replied:
> David Wagner wrote:
> >
> > In article <[EMAIL PROTECTED]>, Terry Ritter
>>_<[EMAIL PROTECTED]> wrote:
> > > But it is also correct that multiple ciphering is provably
strong*er*
> > > in the sense of not allowing known-plaintext and defined-plaintext
> > > attacks on individual ciphers.
> >
> > Well, personally I find that to be an extremely surprising claim.
> > Care to share the formal proof? It would be the first time I know
> > of where one could actually _prove_ that *anything* strictly
increases
> > security.
Didn't Terry qualify his statement in terms of known-plaintext and
defined plaintext?
Is his statement incorrect *with that qualification*?
In a previous post he specified using "thought strong" ciphers, which I
(admitted clueless lurker) don't think a simple XOR qualifies for,
unless you're using three OTP's in succession. So, how do you determine
the three pads so you can XOR them togather to decrypt the ciphertext?
Never mind that, the OTP used once is provably secure, so using it three
times can't make it stronger. Terry hasn't suggested that, he considers
using conventional (more or less) ciphers.
Isn't triple-DES an existing example of stacked multi-ciphering?
Would triple-AES using a twofish-mars-rc6 stack be logically and/or
functionally similiar or identical to triple-DES?
If so, and if feasable known or chosen plaintext attacks against each of
the three were discovered, would the stack be susceptable to a known or
chosen plaintext attack? This appears to me to be the heart of Terry's
proposal. Not that all three would be broken before you changed, but
that if one is broken, the other two protect it. That appears to be
correct logically, but appearances can be deceiving and the real world
doesn't always work logically.
Thanks in advance for any help you can give me in understanding some of
this, and thank you all for discussing this issue. I'm still building a
foundation to base learning upon, and all this helps.
Rick
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: NIST, AES at RSA conference
Date: 6 Feb 2000 12:20:07 -0000
[EMAIL PROTECTED] (Terry Ritter) writes:
> In practice, I think we all know that a cipher which cannot be
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> attacked in the most favorable ways is in some sense "stronger" than
> it would otherwise be.
[snip]
> "Everybody thinks so," is not reasoning.
And here lies the crux of the argument. We haven't proven the
strength of our ciphers, and you haven't proven the strength of your
multiple encryption schemes. You're relying on just the reasoning you
accuse us of.
If we had practical and provably secure ciphers, we would of course be
crazy not to use them. Since we don't, we have to rely on the
guesswork you deride.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: 6 Feb 2000 12:25:32 -0000
Ian Hay <[EMAIL PROTECTED]> writes:
> Xcott Craver wrote:
>
> > o DVD encryption is not there to prevent illegal copying.
> >It does not prevent illegal copying. A pirate will copy the whole
> >DVD without breaking the encryption, and the copy will play in a DVD
> >player. Encryption doesn't even slow him down.
>
> Sorry to butt in, but this seems to be a point of contention. Isn't
> the above statement (while widely believed) specifically untrue? My
> understanding of the description of the technology involved is that
> the encrypted key, read by the software or hardware DVD player, is on
> a specific area of the distributed DVD that is otherwise pre-embossed
> on writeable DVDs. So an attempt to do a bit-for-bit copy results in
> unreadable copy missing that small section of the data.
You're correct AIUI, but there's an even stronger disincentive to the
pirate using blank DVDs: the blanks are more expensive than
commmercial DVD pressings! Thus, the pirates you *really* want to
combat, as another respondant pointed out, are the ones who press the
disks themselves, and the encryption has no effect on them at all.
You can also store and play DVDs from your hard drive if you have the
right software, and again the crypto is no hinderance.
DeCSS was developed for viewing DVDs under Linux.
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: Paul Crowley <[EMAIL PROTECTED]>
Subject: Re: Merkle hash tree patent expired
Date: 6 Feb 2000 12:32:40 -0000
"Roger Schlafly" <[EMAIL PROTECTED]> writes:
> Paul Rubin <[EMAIL PROTECTED]> wrote in message
> news:87dpfs$i2r$[EMAIL PROTECTED]...
> > Hey, nobody seems to have mentioned it here, but apparently US patent
> > 4,309,569 expired on September 5, 1999. This gives a somewhat clunky
> > way of doing digital signatures using only conventional hash functions,
> > no modular exponentiations or elliptic curves or other fancy math.
>
> I didn't notice. Merkle hash trees do have some other applications.
> I am sure there are some folks who are glad the patent has expired.
Where can I find a description of the technique? Is it based on
organising the documents to sign into a balanced tree, signing each
node, and publishing the root? If you used PK to sign the root, you
could have extra-cheap signature verifications that could be useful
for something like DNS...
--
__
\/ o\ [EMAIL PROTECTED] Got a Linux strategy? \ /
/\__/ Paul Crowley http://www.hedonism.demon.co.uk/paul/ /~\
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Random-Width Transposition Tables?
Date: Sun, 06 Feb 2000 14:38:22 GMT
On Sat, 5 Feb 2000 18:32:42 -0800, "r.e.s." <[EMAIL PROTECTED]>
wrote, in part:
>I can only speculate that a rationale to justify such a sacrifice
>of entropy must involve hardening wrt to non-brute-force attacks.
>Is that correct? Is there any "accepted wisdom" about when, whether,
>and/or how much to randomize transposition table-widths?
Yes. If one knows, for a simple columnar transposition, the length of
the key, then one can immediately know the size of the "chunks" to
divide the plaintext into to form the columns which were read out of
the block (the only thing one doesn't know is which chunks contain one
extra odd letter).
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Merkle hash tree patent expired
Date: Sun, 06 Feb 2000 14:41:11 GMT
On 4 Feb 2000 05:53:00 GMT, [EMAIL PROTECTED] (Paul Rubin) wrote, in
part:
>Hey, nobody seems to have mentioned it here, but apparently US patent
>4,309,569 expired on September 5, 1999. This gives a somewhat clunky
>way of doing digital signatures using only conventional hash functions,
>no modular exponentiations or elliptic curves or other fancy math.
And by an odd coincidence, having come across the Diffie-Lamport
technique of doing this in AC when trying to look something else up, I
thought that since it gave important information about the limitations
of non-PKC techniques, I needed to add a description of it to my web
site...just shortly before your post.
John Savard (teneerf <-)
http://www.ecn.ab.ca/~jsavard/index.html
------------------------------
From: [EMAIL PROTECTED] (Dave Hazelwood)
Subject: NSA opens up to US News
Date: Sun, 06 Feb 2000 15:32:18 GMT
http://www.usnews.com/usnews/issue/000214/nsa.htm
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Subject: Scaleable Key Permutation Feature to be Added to CipherText
Date: Sun, 06 Feb 2000 15:37:47 GMT
It has been determined that a new key-building feature can be added the =
CipherText algorithm. It will be optionally used to dynamically scale =
the primary key using its derived attribute value to accommodate =
security requirements. With the feature, it will be possible to encrypt =
a 1300 character message using a ten element key without a single =
repetition of the applied cipher key. The feature is a natural =
progression of earlier work on the algorithm. When combined, the work =
possibly rates as a significant development in the field of cryptology.
Overview:
Presently the CipherText algorithm builds a modified key based on the =
primary key and its attribute. The modified key is shifted according to =
its attribute. Then the key is truncated at one end as defined by the =
attribute. When both keys are then applied, there is no repetition of =
key values until n(n-1) message elements ( where n is the number of key =
elements.) Thus a 600 character message can be encrypted without =
repetition using 25 key elements. This much can be done with the =
description filed in the patent application.
To improve the algorithm's security, the modified key can be built by =
using the result of the attribute % 10 function and appending the =
resulting key in a reiterated process until enough keys exist to ensure =
that no repetition is necessary to encrypt an entire message with unique =
ciphers. The feature can be dynamically scaleable to adjust =
automatically to reasonable message lengths. Using a 10 character key, =
its is normally not necessary to build more than one or two additional =
keys.
EXAMPLE:
A key of ten elements can be modified and appended once to handle a =
message up to 110 characters in length without a repetition. A second =
modified key would append a value based on the attribute of the first =
modified key resulting in 12 elements. The key would be applied as the =
third pass in the cipher, with its index shifting every 110 characters. =
The result is a method to encrypt a 1320 character message without a =
repetition of the applied cipher key. Creation of the fourth key with 13 =
elements makes it possible to use 17160 consecutive unique cipher keys.
It should also be noted that each 2X increase in the length of the =
primary key, results in another 10X increase in the number of unique =
cipher elements.=20
Synopsis:
Key-building capabilities have been seen before, but this has a slightly =
different twist with its open-ended logarithmic scaling feature. =
Converting CipherText to a block format would likely see some =
compromise.
Research to determine the exact nature of related cipher algorithms has =
not revealed anything closely similar to CipherText, however it was =
learned that it falls into the category of 'hashing algorithms.' The =
advanced algorithms in the category are complex block ciphers that =
rotate the plaintext elements of messages through a calculated series of =
changes. CipherText on the otherhand, works by rotating the keys to =
create a wide assortment of permeable cipher combinations. For maximum =
security, this assortment will exceed message length.
U.S. patent application was filed for CipherText on 11-19-99.
-C. Prichard
www.greentv.com
------------------------------
From: "Roger Schlafly" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: permission to do crypto research
Date: Sun, 6 Feb 2000 01:09:40 -0800
According to US copyright law on "circumvention of copyright
protection systems" (17 US 1201), certain encryption research
is permissable only if "the person made a good faith effort to
obtain authorization before the circumvention".
Now I know the law is silly, but does anyone have experience
with authorization requests? Eg, if you write to Microsoft
and ask for permission to hack Windows for research
purposes, what does Microsoft say? Has anyone asked for
permission to crack DVD/CSS encryption?
The law also tries to distinguish whether a published crack
advances research or facillitates infringement. Does anyone
know of this distinction being drawn in a practical situation?
(Some of these issues will arise in the NY DeCSS case.)
------------------------------
From: "C. Prichard" <[EMAIL PROTECTED]>
Crossposted-To: talk.politics.crypto,misc.int-property,misc.legal.computing
Subject: Re: RE
Date: Sun, 06 Feb 2000 17:30:35 GMT
Understanding the context of highlighted phrase "circumvention of =
copyright protection systems" is the key.
First, a "copyright protection system" is something that Windows has on =
its distribution disk. There is no copyright protection system embedded =
in the operating system.
So assuming you want to RE Windows for the purpose of your encryption =
research to find out how the program does something. If the encryption =
method actually has nothing to do with copyright protection of 'Windows' =
itself, then the law would no be applicable.
This might be why Microsoft will not provide some type of copyright =
protection feature. They do not want to assume liability for "breakage." =
(sorry)
The context of DVD/CSS encryption is however quite different. It seems =
that the law is specifically pertaining to the distribution medium of =
copyright materials. By examining the embedded algorithm in the DVD =
player, you are able to explain possible contexts that allow you to =
examine code. I'm guessing that you may legally even go so far as to =
explain your cause in terms of wanting to "see pictures and hear sound" =
using your own implementation of hardware and software. But when you =
become intent on distribution of your product that circumvents the =
copyright protection of the DVD/CSS distribution format, your previous =
work becomes tainted in the eyes of the law.
-C. Prichard
Roger Schlafly <[EMAIL PROTECTED]> wrote in message =
news:87k55g$i5o$[EMAIL PROTECTED]...
> According to US copyright law on "circumvention of copyright
> protection systems" (17 US 1201), certain encryption research
> is permissable only if "the person made a good faith effort to
> obtain authorization before the circumvention".
>=20
> Now I know the law is silly, but does anyone have experience
> with authorization requests? Eg, if you write to Microsoft
> and ask for permission to hack Windows for research
> purposes, what does Microsoft say? Has anyone asked for
> permission to crack DVD/CSS encryption?
>=20
> The law also tries to distinguish whether a published crack
> advances research or facillitates infringement. Does anyone
> know of this distinction being drawn in a practical situation?
> (Some of these issues will arise in the NY DeCSS case.)
>=20
>=20
>=20
>=20
>=20
------------------------------
** 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
******************************
