Cryptography-Digest Digest #400, Volume #13 Fri, 29 Dec 00 00:13:01 EST
Contents:
Re: I may file a complaint with the FBI against some people in the past and
corporations such as Nokia .... .. these charges I file shall be industrial espionage
changes ("Tom ST Denis")
Re: "Content Protection for Recordable Media" ("Joseph Ashwood")
Re: "Content Protection for Recordable Media" (nobody)
Re: "Content Protection for Recordable Media" (Vernon Schryver)
Re: "Content Protection for Recordable Media" (nobody)
Re: "Content Protection for Recordable Media" (Bill Unruh)
Re: "Content Protection for Recordable Media" (Bill Unruh)
Re: "Content Protection for Recordable Media" (nobody)
Re: "Content Protection for Recordable Media" ("Joseph Ashwood")
Re: "Content Protection for Recordable Media" (nobody)
Re: Random keys of arbitrary length (Rkq)
Re: Quick CRT question: (Bryan Olson)
Re: "Content Protection for Recordable Media" ("Joseph Ashwood")
Re: [rijndael] Efficient hardware S-box implementation ("John E. Gwyn")
Re: Newbie ("John E. Gwyn")
Re: ___speak something fair (kctang)
----------------------------------------------------------------------------
From: "Tom ST Denis" <[EMAIL PROTECTED]>
Crossposted-To: alt.2600,alt.security,comp.security
Subject: Re: I may file a complaint with the FBI against some people in the past and
corporations such as Nokia .... .. these charges I file shall be industrial espionage
changes
Date: Thu, 28 Dec 2000 23:14:42 GMT
"Markku J. Saarelainen" <[EMAIL PROTECTED]> wrote in message
news:92g07q$lvs$[EMAIL PROTECTED]...
> Actually I never drunk anything, but they wanted to go to Joensuu in
> Finland to celebrate ... I was a driver ... one was a police officer
> with an advanced electrical training, two others worked for Nokia in
> cellphones ... Tampere ...
>
> Just wondering if Nokia and other people are somehow involved in
> privacy violations in the U.S.A. ... in 1998 Jimmy from 99x called me
> and left a message to me to win a prize .. at the same time there was a
> round trip to Finland advertised by Nokia in the same radio station ...
> well if they violated my privacy, they also commited the crime of
> industrial espionage, because I was the business man / consultant ...
> and they broke the Eeconomic Espionage Act of 1996 of the U.S.A. which
> is the Federal Crime and fall under the jurisdiction of the FBI ... so
> this is the way it is .....
>
> I may contact the FBI and file charges .. so this is the way it will
> be ...
The lesson kids is don't drink and type.
Tom
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "Content Protection for Recordable Media"
Date: Thu, 28 Dec 2000 15:25:09 -0800
Regardless I still like the idea of using a custom driver that simply
filters out the request for protected storage, or for that matter logs all
such requests (to unprotected areas of course), and all data associated with
them, eliminating the effect of the cryptodrive. Of course since we've
already seen that it is now illegal to run whatever software you want
against data you own, on hardware you own, in a location you own (ref
DeCSS), this approach may be declared illegal. Won't stop people though,
once 1 person has alleviated the responsibilities of the hard drive for a
file, and put it up on gnutella or freenet or....... it's not gonna matter.
It also seems to be that a scheme like this deserves to be placed in the
drive controller where it will be of the most use (and where a dongle chip
can be more easily dealt with). From there it behave effectively like a
second hard drive controller, but only for the encrypted sectors. However
that is my own personal preference, and I have no sway on T.13.
Joe
------------------------------
From: [EMAIL PROTECTED] (nobody)
Subject: Re: "Content Protection for Recordable Media"
Date: Thu, 28 Dec 2000 23:58:51 GMT
>But content-protected files, when written to the drive, are in
>encrypted form. And the key to the encryption is written on a part of
>the hard drive which is not directly accessible.
yes and no. the 'content key' and 'usage permissions' are stored as
normal files along with the encrypted content and the extended MKB.
all of these can be read off the drive normally. There are also the
MKB and the dynamic ID which are read off the read-only portions of
the device via the newly defined ATA commands. the above are combined
together to produce the actual key that the content is encrypted with.
>This does create a problem of backup, since what if one wants to take
>this kind of content temporarily off of that hard drive to use the
>space for something else?
is this a problem? surely you can just copy the files (content,
content key, usage file) onto, say, cdrw. when you don't need the disk
space again, just copy it back.
>I think that a general backup feature could have been provided without
>compromising the scheme's security; simply give each of these hard
>drives a serial number, and a unique, secret, encryption key, and
>allow encrypted files to be exported with the key, as encrypted by the
>drive's unique key. That way, one can back up the entire hard drive in
>a normal way, even if it contains a large quantity of content of this
>type from many different providers.
each drive does have a unique serial number: the static ID and the
media unique key (if i understand the specs correctly, they are a
little unclear).
from my understanding, you can backup the entire drive. only you need
to restore to the same drive.
the above is based on my understanding of the docs i have:
e00152r0.pdf, e00148r2.pdf, cpsa081.pdf, 4cspec.pdf. if someone knows
of any other files freely available on CPSA, please let me know.
--
pel
------------------------------
From: [EMAIL PROTECTED] (Vernon Schryver)
Subject: Re: "Content Protection for Recordable Media"
Date: 28 Dec 2000 17:04:49 -0700
In article <[EMAIL PROTECTED]>,
John Savard <[EMAIL PROTECTED]> wrote:
> ...
>Normally, files are written to, and read from, the drive like any
>other drive, and they can be copied.
>
>But content-protected files, when written to the drive, are in
>encrypted form. And the key to the encryption is written on a part of
>the hard drive which is not directly accessible.
>
>The program writing the file to the hard drive specifies something
>like a password, and the viewer program which is the only thing
>allowed to read the file knows this password. Since the password needs
>to be combined with the key on that particular drive to decrypt the
>file, it can only be turned into its unencrypted form by the viewer
>programs that know the right password, and on the specific machine on
>which it was installed.
Notice the fatal similarities to dongles and other software
copy-protection schemes. The reason why such schemes have not
worked for the last 25 years is not because there has never before
been hardware support for copy protection. Remember the antediluvian
hacks involving odd timing or bits on floppies.
Such copy protection schemes might make sense on closed boxes like
satellite TV receivers and DVD players, but they're silly and
hopeless on boxes with standard software tools including those
required to debug WIN32 DLL's. The week after any really interesting
"encrypted" content is published, there will be people who will
have picked the password out of the viewer program.
Never mind the brute force and impossible to defeat attacks that
are variations on the theme of pointing a video camera at a monitor
and making new recordings.
It is wrong to call such stuff "encrypted," since there are
100,000,000's of people with the keys, ciphertext, and devices for
generating cleartext. If this stuff is "encryption," then so are
the many complicated for encoding data involving scrambling
polynomials, zero insertion, and dc bias removal.
> ...
>These two features, then, a disk ID and a means of exchanging it, are
>what is missing to allow the security feature to be acceptable for
>broader use.
No, those are only the features necessary to make it less intolerable
to some users. The main missing feature is the same feature that
has killed copy protection for the last 25 years.
The trouble with copy protection is that it is based on the assumption
that your customers are out to steal from you. In most legitimate
businesses it is a bad idea to assume that many of your customers want
to cheat you. It's necessary to pick a middle ground between cash lying
around and doing body cavity searches on all customers or rigging those
theft detection coils to fire claymore mines instead of ring bells.
It's strange, but marketeers are most likely to err on the side of
body cavity searches and claymores.
--
Vernon Schryver [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (nobody)
Subject: Re: "Content Protection for Recordable Media"
Date: Fri, 29 Dec 2000 00:18:01 GMT
>Such copy protection schemes might make sense on closed boxes like
>satellite TV receivers and DVD players, but they're silly and
>hopeless on boxes with standard software tools including those
>required to debug WIN32 DLL's. The week after any really interesting
>"encrypted" content is published, there will be people who will
>have picked the password out of the viewer program.
i wonder if there will be any software viewers after the decss
incident. maybe they have learned their lesson from that?
--
pel
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: "Content Protection for Recordable Media"
Date: 29 Dec 2000 00:21:12 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (nobody) writes:
]>Dumb quesion: What prevents one from reading from such a
]>drive into memory and writing out to a drive without
]>protection features, which some manufacturers of the world
]>would certainly continue to produce to meet a corresponding
]>market demand?
]the info is stored on the drive in encrypted form. you can copy the
]encrypted files as any other ordinary files. e.g. to a non-compliant
]drive.
]to decrypt, you will need to obtain a licence to get the requisite
]info.
Nice. So they can prevent me from reading my own data? And people would
put up with this? sheesh.
In Canada it is a criminal offence to interfer with anyone's lawful
enjoyment of their own data. This would thus clearly be a criminal
offence in Canada.
------------------------------
From: [EMAIL PROTECTED] (Bill Unruh)
Subject: Re: "Content Protection for Recordable Media"
Date: 29 Dec 2000 00:25:48 GMT
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (nobody) writes:
>from my understanding, you can backup the entire drive. only you need
>to restore to the same drive.
Brilliant. Now this is what backups are for after all. Who would want to
back up data from a computer that had burned in a fire or been stolen
anyway. Such businesses deserver to go under.! :-]
------------------------------
From: [EMAIL PROTECTED] (nobody)
Subject: Re: "Content Protection for Recordable Media"
Date: Fri, 29 Dec 2000 00:29:55 GMT
>]the info is stored on the drive in encrypted form. you can copy the
>]encrypted files as any other ordinary files. e.g. to a non-compliant
>]drive.
>
>]to decrypt, you will need to obtain a licence to get the requisite
>]info.
>Nice. So they can prevent me from reading my own data? And people would
>put up with this? sheesh.
oops. i phrased this rather badly. it is stored on your drive in
encrypted form. it is uploaded to your player which will handle the
decryption so that the content can be played. it is the makers of the
player which will license the technology and info needed to make the
decryption.
--
pel
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "Content Protection for Recordable Media"
Date: Thu, 28 Dec 2000 16:21:39 -0800
> i wonder if there will be any software viewers after the decss
> incident. maybe they have learned their lesson from that?
You mean the lesson that resistance is futile (I couldn't resist, doh,
that's another bad pun, I'll just stop now), or the lesson that things like
this are folly?
Joe
------------------------------
From: [EMAIL PROTECTED] (nobody)
Subject: Re: "Content Protection for Recordable Media"
Date: Fri, 29 Dec 2000 00:41:43 GMT
>> i wonder if there will be any software viewers after the decss
>> incident. maybe they have learned their lesson from that?
>You mean the lesson that resistance is futile (I couldn't resist, doh,
>that's another bad pun, I'll just stop now), or the lesson that things like
>this are folly?
i meant learn there lesson not to license software players.
------------------------------
From: Rkq <[EMAIL PROTECTED]>
Subject: Re: Random keys of arbitrary length
Date: Thu, 28 Dec 2000 19:45:56 -0500
In article <92geva$2rl$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>
>
> > So here's what I've been doing. Basically, I use the hash of a
> passphrase
> > to key a stream cipher, and then use the stream cipher's keystream to
> create
> > keys and IVs:
> >
> > 1. Have the user enter a passphrase. Make sure it's at least twenty
> > characters long.
>
> > 2. Run the passphrase through both SHA1 and MD5 (separately), giving
> > two hashes.
>
> MD5 has a theortical weakness but i don't think it can be exploited.
> There is really no need to run the passphrase through two hashing
> algorithms. One run with SHA-1 is enough, and its faster.
>
> > 3. Concatenate the hashes, giving a 288-bit value, and initialize RC4
> > with that.
>
> This is fine, but RC4 takes 2048-bit keys, and with your method only a
> 288-bit key is supplied. This isn't really a problem, but it appears to
> me that you used two different hashes so you could increase the amount
> of bits you have to initialise.
>
> Its is stupidly unlikely that a 288-bit key could never be broken by
> brute-force. However, you say the minimal excepted length for your
> passphrase is 20 characters. Well a 20 character pass-phrase contains
> only 160-bits, again this isn't a real problem 160-bits will not be
> breakable for the foreseeable future.
You're right, the passphrase should probably be at least as long as the
final hash -- or, in this case, the concatenation of the two independent
hashes.
For an even longer RC4 key, I suppose I could hash with SHA-1 and then run
that through SHA-1 again, and repeat that cycle for however many 160-bit
hashes I wanted. Maybe make the number of hashes dependent on some other
value, for added uncertainty. Then concatenate all the hashes.
>
> > 4. Whenever a random byte is needed, have RC4 return a byte
> > of "keystream"
> > and use that.
> >
> > How secure do you think that is? Is it a good or bad idea to create
> > IVs from the same source as the keys?
>
> It depends on the security of the PRNG, and how the generated key will
> be used.
In this case, RC4 is the PRNG. The key will be used to key either Skipjack
or IDEA, in CBC mode probably.
> The security of the system depends apon its weakest algorithm. MD5 and
> SHA-1 are good algorithms, RC4 is Ok.
True. I'm also aware that RC4 is the weak link. That's one reason why I
thought of mangling RC4's s-box with IDEA periodically. But crypto is
tricky; the IDEA mangle might actually make RC4 _less_ secure.
> If your a real security freak
> insure that you use a BBS-PRNG instead of RC4. A BBS is slower but
> provably secure. Speed really isn't an issue for key-generation.
That said, do you know where I can grab a C implementation of a BBS CSPRNG?
Yes, I could write one, but I'm lazy and I'm sure there's one out there
somewhere. But I haven't been able to find it, yet.
------------------------------
From: Bryan Olson <[EMAIL PROTECTED]>
Subject: Re: Quick CRT question:
Date: Fri, 29 Dec 2000 01:45:20 GMT
Matt Timmermans wrote:
> Bryan Olson wrote:
> > That sum can be larger than Q (even if we add the requirement
> > on a_i that 0 <= a_i < q_i), so we need mod Q at the end. It
> > still runs in O(n^2).
>
> Benjamin's OP said that we are using polynomials over
> GF(2), which don't have this problem. degree(a_i)<degree(q_i),
> so degree(a_i*Q_i)<degree(Q).
Good point; I'd missed that. The question noted both the
polynomial and integer case, and the overflow only applies in
the integer case. We do need the requirement that a_i is a
least residue mod q_i, since otherwise a natural way to find
a_i | a_i*Q_i = r_i mod q_i
would be to multiply the mod q inverse of Q_i by r_i. If we
don't reduce a_i mod q_i it can overflows even in the
polynomial case.
--Bryan
Sent via Deja.com
http://www.deja.com/
------------------------------
From: "Joseph Ashwood" <[EMAIL PROTECTED]>
Subject: Re: "Content Protection for Recordable Media"
Date: Thu, 28 Dec 2000 17:21:26 -0800
But without a software player they will vastly reduce their potential
market, and no reasonable manager would go that route, it's better to have
an insecure system that is widely used, and making lots of money, than it is
to have a secure system that is little used, and making very little money.
Besides do you really think that hardware will be that much stronger?
They've published the spec, it has to go through my computer to work, we
know the exact behavior, it won't be that difficult to create a software
emulator, and then poof!!! all gone.
Joe
"nobody" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> i meant learn there lesson not to license software players.
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: [rijndael] Efficient hardware S-box implementation
Date: Thu, 28 Dec 2000 20:42:25 -0600
Tim Olson wrote:
> It goes on to state that this may be simplified by representing
> elements in GF(256) as a 1st-degree polynomial with coefficients
> in GF(16):
> (bx + c)
> However, I cannot find an easy mapping from the representation of
> elements in GF(256) to the 2 coefficients b & c in GF(16) ...
? Isn't it just b = top 4 bits, c = bottom 4 bits ?
------------------------------
From: "John E. Gwyn" <[EMAIL PROTECTED]>
Subject: Re: Newbie
Date: Thu, 28 Dec 2000 20:44:07 -0600
Darryl Wagoner - WA1GON wrote:
> Any security system has to be secure even if
> the complete source code is disclosed.
More accurately, if security is dependent on the algorithm being
kept secret, that unnecessarily introduces another way in which
security could be compromised.
------------------------------
From: kctang <[EMAIL PROTECTED]>
Subject: Re: ___speak something fair
Date: Fri, 29 Dec 2000 12:52:20 +0800
==============31137760102E06C45D63EE3C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Robert Harley wrote:
>"Michael Scott" <[EMAIL PROTECTED]> writes:
>>Perhaps point-halving is the way to go? Some say yes, others no.
>
>I'm not convinced that it makes a big difference either way. Its
>advocates say most operations are linear. Sure, but that's no
>panacea. Solving l^2+l = a+x costs about 3 or 4 times as much as
>multiplication. A square root costs a bit more than a multiplication.
>And there is a (non-linear) multiplication in there plus some other
>little bits. So you have a cost equivalent to 5 or 6 multiplications
>per point halving. More testing is needed before giving a definitive
>pronouncement, IMO.
In GF(2^n) using NB, square root is essentially free and to solve
an equation of THIS form l^2+l = a+x should not cost more than a
field multiplication. However, more testing is necessary :-)
Yours, kctang
==============31137760102E06C45D63EE3C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Robert Harley wrote:
<br>
<br>>"Michael Scott" <[EMAIL PROTECTED]> writes:
<br>>>Perhaps point-halving is the way to go? Some say yes, others no.
<br>>
<br>>I'm not convinced that it makes a big difference either way.
Its
<br>>advocates say most operations are linear. Sure, but that's no
<br>>panacea. Solving l^2+l = a+x costs about 3 or 4 times as much
as
<br>>multiplication. A square root costs a bit more than a multiplication.
<br>>And there is a (non-linear) multiplication in there plus some other
<br>>little bits. So you have a cost equivalent to 5 or 6 multiplications
<br>>per point halving. More testing is needed before giving a definitive
<br>>pronouncement, IMO.
<br>
<br><tt>In GF(2^n) using NB, square root is essentially free and to solve</tt>
<br><tt>an equation of THIS form l^2+l = a+x should not cost more than
a</tt>
<br><tt>field multiplication. However, more testing is necessary :-)</tt>
<br><tt> </tt>
<br><tt>Yours, kctang</tt>
<br><tt> </tt>
<br> </html>
==============31137760102E06C45D63EE3C==
------------------------------
** 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 by posting to sci.crypt.
End of Cryptography-Digest Digest
******************************
