Cryptography-Digest Digest #695, Volume #12 Sat, 16 Sep 00 21:13:01 EDT
Contents:
Re: ExCSS Source Code (Bryan Olson)
Re: For the Gurus ("root@localhost " <[EMAIL PROTECTED]>)
Re: ExCSS Source Code (David A Molnar)
Re: More Bleh from a Blahish person. ;) (Mok-Kong Shen)
Re: ExCSS Source Code (David A. Wagner)
Re: ExCSS Source Code (David A. Wagner)
Re: ExCSS Source Code (John Savard)
Re: Tying Up Loose Ends - Correction (John Savard)
Re: ExCSS Source Code (Bill Unruh)
Re: Tying Up Loose Ends - Correction (Tim Tyler)
Re: ExCSS Source Code (Eric Lee Green)
Re: Extremely slow in DES software implementation (Eric Young)
Question on self-shrinking (Benjamin Goldberg)
Re: ExCSS Source Code (Bryan Olson)
Re: ExCSS Source Code (Bryan Olson)
Re: Question on self-shrinking (David A. Wagner)
----------------------------------------------------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Sat, 16 Sep 2000 20:45:47 GMT
David A Molnar wrote:
> Also the licensing of players. Since you can't build a
> player without implementing CSS.
There's a net.myth that the purpose of CSS was to control
licensing of players. The DVD consortium already had that
with its patent pool. The conditions to license CSS are
entirely content-control requirements.
CSS is now broken, but it was part of a system of technical
measures that effectively controlled access to copyrighted
works.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "root@localhost <spamthis>" <[EMAIL PROTECTED]>
Subject: Re: For the Gurus
Date: Sat, 16 Sep 2000 18:33:26 -0400
Jim;
Thanks very much for spending time discussing this with me. I have
settled on a system.
It is a 4 square. Each alphabet in each quadrant will be randomly
generated. In addition to that I will use padding (chaffing) by
generating a small matrix and a fifth randomly generated alphabet. I
will elect random cells in the matrix to insert chaff.
The grill in which the chaffing happens is an 11x16 yeilding 176
positoins.
The ratio of 'chaff' to wheat will be established to ensure the key
period is short enough to enhance security somewhat.
Here is an example. I have not finalized my source of random data, the
final dimensions of the matrix, or the chaff/wheat ratio... I should be
able to get four of these on a page but I may place only one or two with
other working aids for the cryppie ;-).
2AKM1C O6Z9GD/-------------------------------------------------\
L3HY6V QJTRPW| . . 5 . . . . . . . 7 . . . . . |
UFQ074 48S325| . . 8 . . . . . . Z . . 4 E . Q |
J8SRWG IXNB0A| . F . . . . . . N . . 5 . 8 . 1 |
5BDOEI LCF1VK| . . . . . 6 . . 8 . H . 9 . . . |
TX9PZN UYEMH7| . . . 7 . . 1 . . Q . 0 N . . C |
| . . . Q . . . H . . K L R V . . |
YA57NM AFB2XE| . Z . . . . W . . . T P C . . 4 |
XLD40C 8JMYHT| . 8 7 . . . M . . . . . . T . . |
HVT9RG C93I6Q| X . R . . . M . . 3 5 . . . R . |
6WIKJB O7GR50| 1 M . . . G . . . 9 D I . . . . |
PZ3FEO ZLKS1U| . . . . . . . L . . . X . I . C |
Q8U2S1 DNWVP4\-------------------------------------------------/
Any thoughts, concerns?
Thanks again for showing me the errors in my ways. It is a bit
cumbersome and I have bad feelings about transcription errors but it is
a start, I think.
-m-
--
If children don't know why their grandparents did what they
did, shall those children know what is worth preserving and what
should change?
http://www.cryptography.org/getpgp.htm
------------------------------
From: David A Molnar <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: 16 Sep 2000 22:48:47 GMT
Bryan Olson <[EMAIL PROTECTED]> wrote:
> David A Molnar wrote:
>> Also the licensing of players. Since you can't build a
>> player without implementing CSS.
> There's a net.myth that the purpose of CSS was to control
> licensing of players. The DVD consortium already had that
> with its patent pool. The conditions to license CSS are
> entirely content-control requirements.
Sorry, what I meant was that you had to license CSS from the consortium
to build a player. In order to license CSS, you need to agree to the
consortium's rules. If you implement CSS otherwise, you're in violation
of patent. So the consortium can control who makes players and what
features the players have.
What do you mean by "entirely content-control requirements"?
It seems that we may agree.
Thanks,
-David
------------------------------
From: Mok-Kong Shen <[EMAIL PROTECTED]>
Subject: Re: More Bleh from a Blahish person. ;)
Date: Sun, 17 Sep 2000 01:19:09 +0200
Simon Johnson wrote:
>
> Every mapping of n bits to n bits has a function that will describe it.
Every mapping of n bits to n bits (when the n bits are
interpreted as a binary number) IS a function. Note
that a function need not be expressed as a mathmatical
expression. In the present discrete case, giving
all the argument-functionvalue pairs, i.e. a table,
is o.k. as well.
> So like: Say we wanted a 8x8 s-box. Instead of using a fixed table, we
> could use an maths function. let F(X) = X + 1 mod 256. We take x and
> compute F(X), F(X) then substitues x. If this doesn't make sense, i
You can either use a table or a mathematical expression.
> Does a function exist that can describe every s-box? If so, then some
> of these functions must duplicate the *best* s-boxes one can produce.
The question is what are the criteria for determining
the 'best' S-boxes. Could you provide a definition
of the 'best' S-boxes. (Isn't the matter at least a
bit like determining the 'most beautiful' girls of
the world?)
> Say i found such a function in GF(2^32). I could then use this one
> function as my entire f-function, in a Feistel based cipher. Lets say i
> added the round key to the plain-text chunk being encrypted, mod
> (2^32). How many rounds would this require before the best linear and
> differential attack requires more known plain-text blocks than exist?
See the follow-up of Douglas Gwyn.
M. K. Shen
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: ExCSS Source Code
Date: 16 Sep 2000 16:05:53 -0700
Bryan Olson <[EMAIL PROTECTED]> wrote:
> There's a net.myth that the purpose of CSS was to control
> licensing of players. The DVD consortium already had that
> with its patent pool. The conditions to license CSS are
> entirely content-control requirements.
The matter is by no means settled, but I think it would be premature to
rule out the possibility that one of the ways that CSS was used was to
control the player market.
You might want to re-examine some of the evidence. This is getting a
bit off-topic for sci.crypt, but I'll list a few examples.
There is evidence that the CSS license incorporates extra restrictions
on what features players must incorporate (e.g., region coding).
And just because the DVD consortium has other patents, too, doesn't mean
that CSS wasn't used as an additional big stick.
See below for a quote from one document (_not_ from the DVD CSS designers,
but from a related content protection group -- one of the DVD 4C entities)
that suggests that -- at least in some cases -- the industry views crypto
as a way to control the player market.
``The protection comes from compliant devices responding appropriately
to manage the content according to the [information carried with the
content that indicates conditions constraining its use]. Such protection
is realized only if there is some means, or "hook", to compel devices
to be compliant.
Encryption is that hook.''
The above excerpt is taken from "Content Protection System Architecture",
dated Feb 17 2000, revision 0.81, p. 7, by Intel, IBM, Matsushita, and
Toshiba. See http://www.dvdcca.org/4centity/data/tech/cpsa/cpsa081.pdf
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: ExCSS Source Code
Date: 16 Sep 2000 16:14:57 -0700
Bryan Olson <[EMAIL PROTECTED]> wrote:
> CSS is now broken, but it was part of a system of technical
> measures that effectively controlled access to copyrighted
> works.
Be careful. This statement can be misleading without some context.
What most readers what might not realize is that you are using the word
`effective' in a counter-intuitive way. I'm guessing that you are
probably referring to the definition of `effective' in the DMCA, which
only requires that the crypto "have the effect of controlling access",
not that it "be effective at controlling access". (I hope the distinction
is clear; the fact that the English language uses the same word for the
two concepts makes it hard to avoid confusion.) As used in the DMCA,
the word `effective' is essentially a legal no-op.
In other words, there is no requirement in the DMCA that the crypto
resist attack. It is not clear where the line was intended to be drawn;
as far as I can tell, it even appears possible that ROT13 (or its keyed
variant, ROT_k, where k is a secret key) could qualify as "a technical
measure that effectively controls access to copyrighted works".
Apologies for the off-topic post.
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: ExCSS Source Code
Date: Sat, 16 Sep 2000 23:08:11 GMT
On Sat, 16 Sep 2000 20:45:47 GMT, Bryan Olson <[EMAIL PROTECTED]>
wrote, in part:
>CSS is now broken, but it was part of a system of technical
>measures that effectively controlled access to copyrighted
>works.
Certainly the use of the word 'effectively' in the DMCA had the
meaning of 'in effect' rather than 'is effective', since otherwise
illegally cracking a protection scheme would automatically make it
legal to have cracked it. Also, the word 'efficaciously' would have
been the one used for the second meaning.
And, since the technical fix for the breaking of CSS is not just
retrofitting players, but seizing every DVD disc in existence - and
since our society _depends_ on people's honesty in not taking
advantage of every opportunity to steal or do injury, I found more
than one part of "Emmanuel Goldstein"'s analysis underwhelming.
I still think the DMCA is a bad law, but that is a separate issue. The
only potentially valid argument in the defence of people distributing
the crack would be that insofar as the DMCA made their actions
illegal, it was unconstitutional - because of the First Amendment. But
that defense was also rejected by the courts, and on the basis of
reasons that appear to be largely valid.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (John Savard)
Subject: Re: Tying Up Loose Ends - Correction
Date: Sat, 16 Sep 2000 22:59:48 GMT
On Sat, 16 Sep 2000 18:53:01 +0200, Mok-Kong Shen
<[EMAIL PROTECTED]> wrote, in part:
>If one doesn't care the so-called 1-1 property of Scott,
>then one can simply create an end-of-file symbol in
>the Huffman scheme and then fill to whatever boundary
>one wants.
I think that trying to remove redundancy as far as possible is a good
idea. While I disagree with Mr. Scott on one detail on his 1-1 scheme,
I think that it is preferable to take a little extra trouble than to
be simplistic.
John Savard
http://home.ecn.ab.ca/~jsavard/crypto.htm
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: ExCSS Source Code
Date: 16 Sep 2000 23:26:00 GMT
In <8q0uth$pgt$[EMAIL PROTECTED]> [EMAIL PROTECTED]
(David A. Wagner) writes:
]Bryan Olson <[EMAIL PROTECTED]> wrote:
]> CSS is now broken, but it was part of a system of technical
]> measures that effectively controlled access to copyrighted
]> works.
]Be careful. This statement can be misleading without some context.
]What most readers what might not realize is that you are using the word
]`effective' in a counter-intuitive way. I'm guessing that you are
]probably referring to the definition of `effective' in the DMCA, which
]only requires that the crypto "have the effect of controlling access",
]not that it "be effective at controlling access". (I hope the distinction
]is clear; the fact that the English language uses the same word for the
]two concepts makes it hard to avoid confusion.) As used in the DMCA,
]the word `effective' is essentially a legal no-op.
]In other words, there is no requirement in the DMCA that the crypto
]resist attack. It is not clear where the line was intended to be drawn;
]as far as I can tell, it even appears possible that ROT13 (or its keyed
]variant, ROT_k, where k is a secret key) could qualify as "a technical
]measure that effectively controls access to copyrighted works".
Actually my reading was that since a CD cannot be read in a floppy disk
drive, just putting it on CD controlled access and thus brought
DCMA into force. The law is totally incompetently written. As usual
lawmakers create an absurdly broad law, and assume that the courts will
straighten out the mess. Like my favourite example which is that
according to the criminal code of Canada, it is illegal to operate a
computer ( it is illegal to alter or destroy any data, without any
colour of right as a defence).
------------------------------
From: Tim Tyler <[EMAIL PROTECTED]>
Subject: Re: Tying Up Loose Ends - Correction
Reply-To: [EMAIL PROTECTED]
Date: Sat, 16 Sep 2000 23:02:34 GMT
John Savard <[EMAIL PROTECTED]> wrote:
: http://home.ecn.ab.ca/~jsavard/crypto/mi060303.htm
: the page entitled "Tying Up Loose Ends", to the four awkward schemes I
: provided to deal with the fact that a pseudo-Morse code always has one
: symbol less than the Huffman code to which it corresponds, I have now
: provided a scheme which is both efficient and which avoids
: backtracking.
I would still like to see an implementation of these method, in order to
empirically check whether they actually succeed in removing all bias from
the last byte of typical compressed files.
Alternatively, of the five methods, I would be interested to learn which
of them is claimed to remove any bias. It seems that method 1 still
leaves a (slight) bias. Are the other proposed methods superior in
this respect?
--
__________ Lotus Artificial Life http://alife.co.uk/ [EMAIL PROTECTED]
|im |yler The Mandala Centre http://mandala.co.uk/ Namaste.
------------------------------
From: Eric Lee Green <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Sat, 16 Sep 2000 16:58:53 -0700
Bryan Olson wrote:
>
> David A Molnar wrote:
>
> > Also the licensing of players. Since you can't build a
> > player without implementing CSS.
>
> There's a net.myth that the purpose of CSS was to control
> licensing of players. The DVD consortium already had that
> with its patent pool.
Does this patent pool cover player software? (We already know they cover the
actual hardware).
> The conditions to license CSS are
> entirely content-control requirements.
Do we know these conditions? Oh, I forget, Crytome ( http://www.cryptome.org )
has published one of the licenses. Are you sure that all of the terms in the
license at http://cryptome.org/dvdcca-css.zip deal entirely with
content-control requirements?
> CSS is now broken, but it was part of a system of technical
> measures that effectively controlled access to copyrighted
> works.
Or so a federal judge has ruled. The "effectively controlled" part is what
results in Fair Use problems, because it basically says that when you buy a
DVD, you cannot access it in ways that you wish, you can only access it in
ways that the DVDCCA wishes (via its "effectively controlled access"
mechanisms). Such as not being able to skip commercials. This is similar to a
book publisher saying that once you obtain a book, you must access it from
page 1 to page 500, and you are forbidden under penalty of law to skip the
advertising that is inserted on every other page and also forbidden under
penalty of law from including snippets of the book as part of a review. The
question is whether a) this violates your property rights as the owner of the
physical object (whether it be a book or a DVD), and b) does this prohibition
against including "reasonable" amounts of material in your reviews violate
your 1st Amendment right to engage in critical speech? As the VCR goes the way
of the 8-track tape, the latter is especially going to become an issue of
concern.
--
Eric Lee Green [EMAIL PROTECTED]
Software Engineer "The BRU Guys"
Enhanced Software Technologies, Inc. http://www.estinc.com/
(602) 470-1115 voice (602) 470-1116 fax
------------------------------
From: Eric Young <[EMAIL PROTECTED]>
Subject: Re: Extremely slow in DES software implementation
Date: Sun, 17 Sep 2000 00:12:02 GMT
Kasper Pedersen wrote:
> "P.C. Teo" <[EMAIL PROTECTED]> wrote in message
> news:8psqqj$fg3$[EMAIL PROTECTED]...
> > I am implementing a standard DES software (Downloaded from Internet) in my
> > project. I found that it takes around 25+ seconds to encrypt a 1MB file
> but
> > PGP takes less than 4 seconds.
> Hoping not to sound like too annoying:
> I implemented DES in optimized assembler for Pentium-II/K6 and newer cpu's.
> around 2.5MHz on a K7TB-700 (running 16 rounds).
On a pentium II 350mhz (NT), a particular widly distributed free DES
implementation gets 5.95 Mbytes/sec for DES-CBC and
2.34 for DES-EDE-CBC mode (triple DES). This is C code.
The pentium Assember code is 8.1 Mbytes/sec and 2.9 Mbytes/sec.
I would sugest you look for a different DES implementation :-)
eric
------------------------------
From: Benjamin Goldberg <[EMAIL PROTECTED]>
Subject: Question on self-shrinking
Date: Sun, 17 Sep 2000 00:26:14 GMT
I was recently thinking a bit about self-shrinking LFSR generators,
and was wondering... are there any differences between the following
four methods:
do {
a = lfsr_bit();
b = lfsr_bit();
} while( a ); return b;
do {
a = lfsr_bit();
b = lfsr_bit();
} while( b ); return a;
do {
a = lfsr_bit();
b = lfsr_bit();
} while( a == b ); return a; // or b, which is just !a
do {
a = lfsr_bit();
b = lfsr_bit();
} while( a != b ); return a; // or b, which equals a
Also, what other psuedo random bit generators are made [more] secure by
self-shrinking? I know LFSR without shrinking isn't secure, and I think
I've seen an occasion of it [shrinking] being used with a lagged
fibbonacci sequence, but what others would it be good for? Would LCG be
secure with shrinking, assuming we used a large enough modulus to
prevent brute force of the state?
--
... perfection has been reached not when there is nothing left to
add, but when there is nothing left to take away. (from RFC 1925)
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Sun, 17 Sep 2000 00:25:10 GMT
> David A Molnar wrote:
[...]
> What do you mean by "entirely content-control requirements"?
To get a CSS license, a manufacture had to agree never to
make players that would allow certain kinds of access to the
material on encrypted disks. There were also some
supporting agreements such as penalties for revealing
secrets that would break the system.
To get CSS licenses, manufacturers did _not_ have to pay a
fee. They did not have to limit competition with other
player manufacturers. They were not restricted from making
players superior to those from DVD consortium members.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: ExCSS Source Code
Date: Sun, 17 Sep 2000 00:48:11 GMT
David A. Wagner wrote:
> The matter is by no means settled, but I think it would
> be premature to rule out the possibility that one of the
> ways that CSS was used was to control the player market.
If I had a way to control the player market, I think I could
figure out a more profitable strategy than giving away
licenses to my competitors without charge.
[...]
> ``The protection comes from compliant devices responding appropriately
> to manage the content according to the [information carried with the
> content that indicates conditions constraining its use]. Such
protection
> is realized only if there is some means, or "hook", to compel
devices
> to be compliant.
>
> Encryption is that hook.''
The text before the quoted portion shows that "The
protection" refers to the protection of the content from the
disk, not protection of anyone's space in the player market.
--Bryan
--
email: bolson at certicom dot com
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED] (David A. Wagner)
Subject: Re: Question on self-shrinking
Date: 16 Sep 2000 18:02:09 -0700
Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> I was recently thinking a bit about self-shrinking LFSR generators,
> and was wondering... are there any differences between the following
> four methods:
Not really.
> do {
> a = lfsr_bit();
> b = lfsr_bit();
> } while( a ); return b;
>
> do {
> a = lfsr_bit();
> b = lfsr_bit();
> } while( b ); return a;
These two are clearly equivalent; you can just swap the initial
states of the two registers. The output of the latter scheme
with initial fill (x,y) is the same as the output of the former
scheme with initial fill (y,x).
If you replace 'while(a)' with 'while(!a)' in the first scheme,
you get something which is apparently not exactly simulable with
either of the two above schemes, but which appears unlikely to be
any better or worse than the above two schemes. It is also
equivalent to the third and fourth schemes you suggested (see
below for why).
A fifth scheme is equivalent to your first and second scheme:
do {
a = lfsr_bit();
b = lfsr_bit();
} while( a != b ); return a;
The output of this third scheme with initial fill (x,y) is the
same as the output of the second scheme with initial fill (x,x+y).
(Here + denotes xor.) This works because LFSR's are linear.
------------------------------
** 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
******************************
