Cryptography-Digest Digest #976, Volume #10 Tue, 25 Jan 00 23:13:02 EST
Contents:
Re: Court cases on DVD hacking is a problem for all of us (Greg)
Re: discussions/articles about about third party authentication models?
([EMAIL PROTECTED])
Re: discussions/articles about about third party authentication models? (Peter
Broadhead)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
Re: Court cases on DVD hacking is a problem for all of us (Samuel Paik)
Re: Intel 810 chipset Random Number Generator (Michael Kagalenko)
----------------------------------------------------------------------------
From: Greg <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Wed, 26 Jan 2000 03:14:25 GMT
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> http://slashdot.org/article.pl?sid=00/01/25/0827258
>
> This has the potential to stop a lot of what is being done in the
> cryptographic industry. What Jon and a few others did was to reverse
> engineer an existing crypto algorithm, find out its weaknesses, and
> then use and publish their knowledge.
>
> Question yourselves - how many of us professional and hobbyist
> cryptographers haven't reverse engineered crypto algorithms?
>
> I have.
>
> Jon Johansen also did - and then found out that Hollywood used their
> influenses to get the Norwegian government to take him in for
> questioning, sieze his equipment, threatening him (and his father)
> with several years in prison.
>
> Do what you feel needs to be done - especially those of you that are
> "well known names in the industry".
>
> ___/
> _/ - in support of Jon Johansen
>
> Also, more info on http://www.opendvd.org
>
>
Boycott the shit out of every company suing him.
And if you want to post similar discoveries, do
so anonymously. That is what I would get out of
all of this.
--
The only vote that you waste is the one you never wanted to make.
RICO- we were told it was a necessary surrender of our civil liberties.
Asset Forfeiture- the latest inevitable result of RICO.
http://www.ciphermax.com/book
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: discussions/articles about about third party authentication models?
Date: Wed, 26 Jan 2000 03:21:09 GMT
On Tuesday, January 25, 2000 6:33 AM, Mike Rosing
[SMTP:[EMAIL PROTECTED]] wrote:
> Peter Broadhead wrote:
> >
> > I am interested in conceptual models or practical implementations of
> > third party authentication in otherwise two party data transactions,
> > in which there are large numbers of different potential parties at
> > each end of the data exchanges.
>
> There are a lot of different kinds of papers in the literature.
> I'm not familiar with this line of research tho.
>
> > I am particularly interested to know whether there are any articles or
> > discussions of conceptual models where there are a very large number
> > of "banks" (and a very large number of "supermarkets"), and there is
> > not the capacity for Ted to have the same passphrase with each "bank".
> > So Ted now has to have the capacity to handle (preferably very simply)
> > authorising (through authentication) transactions between a large
> > number of different parties.
>
> The problem is that this is dangerous. If there's one failure, then
> all of Ted's data and privacy is public. However, the same passphrase
> might give rise to different keys, so not all is lost so long as is it
> isn't Ted's fault.
Not sure that I follow. If you mean having one passphrase is
dangerous, then I agree. Here in Australia it is common practice for
banks to allow customers to choose their PIN numbers (the [usually 4
digit] numbers by which a customer verifies the use of their credit or
debit card in a transaction). This has the advantage for customers of
making it easier to remember their PIN, especially if they have
several cards and choose the same PIN for all of them. But it does
have the obvious disadvantage that if one PIN is disclosed they are
all disclosed.
Be that as it may, I was actually suggesting that this NOT be a
feature of the approaches I am looking for. Are you suggesting that
the latter is dangerous (presumably for other reasons)?
>
> > My pref. would be to have the card app do the key generation, or else
> > have an offcard app. within Ted's control (eg on his PC), together
> > with a routine to load the new key set on to the card if and only if
> > Ted has "opened" the card using his PIN or thumb or whatever.
>
> You need to combine the banks info with Ted's to create a new key for
> that bank. This is easy to do.
My apologies, but again I am unclear what you mean.
I think the authentication process has to be generic (ie not specific
to the bank) if it is to be standard across all banks. But I do agree
(if this is what you mean) that the identification of the bank has to
be verified, and data exchange has to be secure between Ted and the
bank and between the bank and the 'supermarket' (lets use 'Alice'
instead). I suspect this involves using double encryption - or
encryption with first one key, then of the resulting ciphertext with
another. Is this what you meant by a "new key"?
A simplified sketch of part of a possible approach is as follows:
Ted or Alice has to initiate a session with the bank. Lets say it's
Ted. Ted must have registered his public key with the bank at some
earlier time. Ted uses his private key and then the bank's public key
to double encrypt a message made up of the bank's public key (element
1), and Alice's public key (element 2), and sends this together with
his public key (which is associated with his unique account number at
the bank) encrypted using only the bank's public key, to the bank. The
bank verifies that it is in fact Ted at the other end, and not just
someone using Ted's public key, by first decrypting the message with
their private key, compare the public key in the message with that
registered with them for Ted and the use the latter to decrypt
elements containing their own public key and Alice's public key. If
the decrypted text in element 1 matches their public key, then they
know that it is Ted (or at least Ted's private key) at the other end.
The bank then uses Alice's public key from Ted's message and its
private key to send data to Alice about Ted, knowing that Ted has
agreed to this since he supplied Alice's key encrypted with his
private key. Alice decrypts using her private key and the banks
public key. Only she can access the data, and only the bank can have
sent it.
End of sketch.
Ted is authenticated, and must have agreed to the supply of data to
Alice. Only Alice can read the data about Ted that the bank sends
her, and only the bank can have sent the data.
This approach can be used for consent in advance (as time can elapse
between Ted's sending the bank Alice's public key and the subsequent
sending of Ted's data by the bank to Alice), as well as real time
consent.
One potential weakness, not covered in the sketch, is that a bogus Ted
might attempt to have his public key associated with the real Ted's
data at the bank. This has to be addressed through the bank's
procedures by which data about Ted is associated with Ted's public
key. This should be done at the time that Ted opens an account. It
also has to be addressed in key revocation and change procedures, so
that someone other than Ted cannot revoke Ted's key and replace it
with theirs.
Another potential weakness is the association of Alice with Alice's
public key. If Bob manages to get his public key used, in place of
Alice's, then Bob can intercept and access the data about Ted. A
special case of this problem is if Bob and Alice collude such that
Alice knowingly supplies Bob's public key in place of her own. This
has to be addressed through the process by which Ted accesses Alice's
public key and verifies that it is in fact Alice's.
As you can see, I am not even close to a complete conceptual model
for the process, nor do I think it is easy to devise one. But it
seems to me the kind of problem that must have a huge potential
application, and so will have been addressed to some extent in the
literature. Hence my post :-)
> >
> > Can anyone point me to any discussions of conceptual models or
> > articles which discuss this sort of approach? Is there anyone doing it
> > in practice?
>
> I think Stefan Brands thesis would be a good place to start. It's very
> mathematical and generalized, but my reading of it indicates it would
> be the type of solution you're looking for.
Thanks for this. I have found and downloaded some docs on his work.
> Interesting problem description. In Brands book he describes the
> "prover" and the "verifier". He also shows how mathematical relations can be
> proved with zero knowledge. This might help Ted create an unique equation
> that represents his desires to all parties, and they can verify the data they
> need without going to a third party. I think the problem is that Ted
> has to be "online" when the transaction takes place, but this is the same as
> using a credit card today in a store. so I would think it's straight
> forward (but expensive!)
I think the approach sketched above allows consent-in-advance and
batched messaging.
Incidentally, I notice that you are with the Uni of Wisconsin School
of Medicine. The actual purpose of my enquiry is that I wish to
tackle the problem of electronic exchange of health data (eg pathology
results, prior medical history, hospital discharge summaries etc.).
I dont think there any special or additional problems in taking to
electronic exchange those health data communications which are *two*
party exchanges (eg pathology request and results supply between
ordering doctor and pathologist). I believe these are adequately
dealt with, conceptually, in existing models, although practical
implementation is not necessarily well advanced, as electronic health
data exchange is still nascent, and there are standards issues to be
addressed and so on.
The problem with which I am concerned is, for example, where a person
may wish to have their current treating clinician access previous
pathology results not ordered by that clinician, or details of a
hospitalisation where that clinician was not the admitting physician,
and so on. This access can potentially be made much quicker and
easier using electronic exchange, and may be relevant to improving
clinical care, particularly for people with complex conditions with
many different services involved (eg home nursing, occasional hospital
episodes, primary care physician etc) or for assembling and reviewing
attempted treatments for a people wwith intractable conditions, ie
where they have tried a number of clinicians and treatments over time,
but without success.
But in the absence of a transaction model which includes the knowledge
and consent of the person whom the data is about, such exchanges poses
a *huge* challenge to the privacy of personal health information.
Indeed there is a risk that exchanges will end up being done using
more readily available two party transaction models (data provider <->
data recipent) without the knowledge and consent of the person about
whom data is being exchanged. I suspect that this will not prove
tenable, as the public and so legislators would move against such
unconstrained exchange.
Hence my interest in pursuing a three party transaction model, in
which Ted consents to Alice accessing data about him, held and
supplied by another party (referred to in the sketch as "the bank" but
which in practice would be a hospital, pathology company, other
clinician, etc.)
cheers
PB
------------------------------
From: [EMAIL PROTECTED] (Peter Broadhead)
Subject: Re: discussions/articles about about third party authentication models?
Date: Wed, 26 Jan 2000 03:28:05 GMT
On Tuesday, January 25, 2000 6:33 AM, Mike Rosing
[SMTP:[EMAIL PROTECTED]] wrote:
> Peter Broadhead wrote:
> >
> > I am interested in conceptual models or practical implementations of
> > third party authentication in otherwise two party data transactions,
> > in which there are large numbers of different potential parties at
> > each end of the data exchanges.
>
> There are a lot of different kinds of papers in the literature.
> I'm not familiar with this line of research tho.
>
> > I am particularly interested to know whether there are any articles or
> > discussions of conceptual models where there are a very large number
> > of "banks" (and a very large number of "supermarkets"), and there is
> > not the capacity for Ted to have the same passphrase with each "bank".
> > So Ted now has to have the capacity to handle (preferably very simply)
> > authorising (through authentication) transactions between a large
> > number of different parties.
>
> The problem is that this is dangerous. If there's one failure, then
> all of Ted's data and privacy is public. However, the same passphrase
> might give rise to different keys, so not all is lost so long as is it
> isn't Ted's fault.
Not sure that I follow. If you mean having one passphrase is
dangerous, then I agree. Here in Australia it is common practice for
banks to allow customers to choose their PIN numbers (the [usually 4
digit] numbers by which a customer verifies the use of their credit or
debit card in a transaction). This has the advantage for customers of
making it easier to remember their PIN, especially if they have
several cards and choose the same PIN for all of them. But it does
have the obvious disadvantage that if one PIN is disclosed they are
all disclosed.
Be that as it may, I was actually suggesting that this NOT be a
feature of the approaches I am looking for. Are you suggesting that
the latter is dangerous (presumably for other reasons)?
>
> > My pref. would be to have the card app do the key generation, or else
> > have an offcard app. within Ted's control (eg on his PC), together
> > with a routine to load the new key set on to the card if and only if
> > Ted has "opened" the card using his PIN or thumb or whatever.
>
> You need to combine the banks info with Ted's to create a new key for
> that bank. This is easy to do.
My apologies, but again I am unclear what you mean.
I think the authentication process has to be generic (ie not specific
to the bank) if it is to be standard across all banks. But I do agree
(if this is what you mean) that the identification of the bank has to
be verified, and data exchange has to be secure between Ted and the
bank and between the bank and the 'supermarket' (lets use 'Alice'
instead). I suspect this involves using double encryption - or
encryption with first one key, then of the resulting ciphertext with
another. Is this what you meant by a "new key"?
A simplified sketch of part of a possible approach is as follows:
Ted or Alice has to initiate a session with the bank. Lets say it's
Ted. Ted must have registered his public key with the bank at some
earlier time. Ted uses his private key and then the bank's public key
to double encrypt a message made up of the bank's public key (element
1), and Alice's public key (element 2), and sends this together with
his public key (which is associated with his unique account number at
the bank) encrypted using only the bank's public key, to the bank. The
bank verifies that it is in fact Ted at the other end, and not just
someone using Ted's public key, by first decrypting the message with
their private key, compare the public key in the message with that
registered with them for Ted and the use the latter to decrypt
elements containing their own public key and Alice's public key. If
the decrypted text in element 1 matches their public key, then they
know that it is Ted (or at least Ted's private key) at the other end.
The bank then uses Alice's public key from Ted's message and its
private key to send data to Alice about Ted, knowing that Ted has
agreed to this since he supplied Alice's key encrypted with his
private key. Alice decrypts using her private key and the banks
public key. Only she can access the data, and only the bank can have
sent it.
End of sketch.
Ted is authenticated, and must have agreed to the supply of data to
Alice. Only Alice can read the data about Ted that the bank sends
her, and only the bank can have sent the data.
This approach can be used for consent in advance (as time can elapse
between Ted's sending the bank Alice's public key and the subsequent
sending of Ted's data by the bank to Alice), as well as real time
consent.
One potential weakness, not covered in the sketch, is that a bogus Ted
might attempt to have his public key associated with the real Ted's
data at the bank. This has to be addressed through the bank's
procedures by which data about Ted is associated with Ted's public
key. This should be done at the time that Ted opens an account. It
also has to be addressed in key revocation and change procedures, so
that someone other than Ted cannot revoke Ted's key and replace it
with theirs.
Another potential weakness is the association of Alice with Alice's
public key. If Bob manages to get his public key used, in place of
Alice's, then Bob can intercept and access the data about Ted. A
special case of this problem is if Bob and Alice collude such that
Alice knowingly supplies Bob's public key in place of her own. This
has to be addressed through the process by which Ted accesses Alice's
public key and verifies that it is in fact Alice's.
As you can see, I am not even close to a complete conceptual model
for the process, nor do I think it is easy to devise one. But it
seems to me the kind of problem that must have a huge potential
application, and so will have been addressed to some extent in the
literature. Hence my post :-)
> >
> > Can anyone point me to any discussions of conceptual models or
> > articles which discuss this sort of approach? Is there anyone doing it
> > in practice?
>
> I think Stefan Brands thesis would be a good place to start. It's very
> mathematical and generalized, but my reading of it indicates it would
> be the type of solution you're looking for.
Thanks for this. I have found and downloaded some docs on his work.
> Interesting problem description. In Brands book he describes the
> "prover" and the "verifier". He also shows how mathematical relations can be
> proved with zero knowledge. This might help Ted create an unique equation
> that represents his desires to all parties, and they can verify the data they
> need without going to a third party. I think the problem is that Ted
> has to be "online" when the transaction takes place, but this is the same as
> using a credit card today in a store. so I would think it's straight
> forward (but expensive!)
I think the approach sketched above allows consent-in-advance and
batched messaging.
Incidentally, I notice that you are with the Uni of Wisconsin School
of Medicine. The actual purpose of my enquiry is that I wish to
tackle the problem of electronic exchange of health data (eg pathology
results, prior medical history, hospital discharge summaries etc.).
I dont think there any special or additional problems in taking to
electronic exchange those health data communications which are *two*
party exchanges (eg pathology request and results supply between
ordering doctor and pathologist). I believe these are adequately
dealt with, conceptually, in existing models, although practical
implementation is not necessarily well advanced, as electronic health
data exchange is still nascent, and there are standards issues to be
addressed and so on.
The problem with which I am concerned is, for example, where a person
may wish to have their current treating clinician access previous
pathology results not ordered by that clinician, or details of a
hospitalisation where that clinician was not the admitting physician,
and so on. This access can potentially be made much quicker and
easier using electronic exchange, and may be relevant to improving
clinical care, particularly for people with complex conditions with
many different services involved (eg home nursing, occasional hospital
episodes, primary care physician etc) or for assembling and reviewing
attempted treatments for a people wwith intractable conditions, ie
where they have tried a number of clinicians and treatments over time,
but without success.
But in the absence of a transaction model which includes the knowledge
and consent of the person whom the data is about, such exchanges poses
a *huge* challenge to the privacy of personal health information.
Indeed there is a risk that exchanges will end up being done using
more readily available two party transaction models (data provider <->
data recipent) without the knowledge and consent of the person about
whom data is being exchanged. I suspect that this will not prove
tenable, as the public and so legislators would move against such
unconstrained exchange.
Hence my interest in pursuing a three party transaction model, in
which Ted consents to Alice accessing data about him, held and
supplied by another party (referred to in the sketch as "the bank" but
which in practice would be a hospital, pathology company, other
clinician, etc.)
cheers
PB
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 26 Jan 2000 03:36:11 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86iuon$qct$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Michael Kagalenko) wrote:
]
]> That is not the way random numbers should be generated. That's why
]> I did not propose to generate them this way.
]
]Did it ever occur to you that if EVERYBODY misunderstands your
]posts the problem may be at your end? Did it ever occur to you
]that refusing to elaborate, defend, or answer questions about
]what you post is a less than optimal way of dealing with the
]fact that nobody understands what you write?
I will elaborate as soon as I notice that my previous explanation
was read. So far, no one shows any signs of having done so. I am not
going to.
BTW, did EVERYBODY appointed you to speak for them ? Did it occur
to you that those who understood what I am saying are less liley to object ?
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Subject: Re: Intel 810 chipset Random Number Generator
Date: 26 Jan 2000 03:39:46 GMT
Reply-To: [EMAIL PROTECTED]
Guy Macon ([EMAIL PROTECTED]) wrote
]In article <86gsfn$7lu$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
](Vernon Schryver) wrote:
]
]>In other words, as far as I can tell, while it must be true that crystals
]>in computers do have random thermal noise, there are other, far better
]>sources of true randomness in computers than naively comparing crystals.
]
]That was also my conclusion. I previously posted that a simple crystal
]oscillator on your prallel port followed by A Von neuman compensator
]is a cheap source of not very good random numbers, and that XORing
]even such a not very good source with a top of the line PRNG that is
]seeded by the cheap source of not very good random numbers would be
]a big improvement over the PRNG alone. Someone said that a simple
]oscillator using a 555 might be even better. I am thinking about that.
]
That's totally unrelated to the method that I proposed.
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 26 Jan 2000 03:38:26 GMT
Reply-To: [EMAIL PROTECTED]
Terry Ritter ([EMAIL PROTECTED]) wrote
]
]I missed the previous message, but...
]On 25 Jan 2000 09:23:15 -0500, in <86kbkj$[EMAIL PROTECTED]>,
]in sci.crypt [EMAIL PROTECTED] (Herman Rubin) wrote:
]
]>In article <eYOO80rZ$GA.220@cpmsnbbsa04>,
]>Joseph Ashwood <[EMAIL PROTECTED]> wrote:
]>>> All I need to do is measure the clock drift. Aging of the crystal can
]>>> be corrected with re-calibartion.
]>
]>>But that itself introduces biases in the numbers generated.
]>>Let's take a probably not all that great example. Lets take a crystal of
]>>frequency F(with a random component measurably small),
]
]Not only is noise-based quartz crystal jitter "measurably small," it
]is also bipolar, normally-distributed, and independent on a
]cycle-by-cycle basis. It does not produce long-term frequency
]variations, it produces a wider "bandwidth."
It produces clock drift, which can be measured to produce numbers as random
as the thermal noise from a resistor.
------------------------------
From: Samuel Paik <[EMAIL PROTECTED]>
Subject: Re: Court cases on DVD hacking is a problem for all of us
Date: Wed, 26 Jan 2000 03:49:15 GMT
Greg wrote:
> And if you want to post similar discoveries, do
> so anonymously. That is what I would get out of
> all of this.
The CSS algorithm details *were* posted anonymously. It isn't
clear from here whether the DeCSS authors reverse-engineered
the algorithm independently, were the originators of the post,
or relied on the information in the post. They apparently found
the player key from examining the executable of a software DVD player.
--
Samuel S. Paik | http://www.webnexus.com/users/paik/
3D and multimedia, architecture and implementation
Solyent Green is kitniyos!
------------------------------
From: [EMAIL PROTECTED] (Michael Kagalenko)
Crossposted-To: sci.physics
Subject: Re: Intel 810 chipset Random Number Generator
Date: 26 Jan 2000 03:47:48 GMT
Reply-To: [EMAIL PROTECTED]
Terry Ritter ([EMAIL PROTECTED]) wrote
]
]Again, I missed the previous message...
]On 25 Jan 2000 09:19:50 -0500, in <86kbe6$[EMAIL PROTECTED]>,
]in sci.crypt [EMAIL PROTECTED] (Herman Rubin) wrote:
]
]>In article <86gd0n$qmf$[EMAIL PROTECTED]>,
]>Michael Kagalenko <[EMAIL PROTECTED]> wrote:
]
]>>[...]
]>> What I am pointing out that to the extent
]>> that quartz crystal, any quartz crystal, dissipates mechanical energy,
]>> it will produce thermally random noise, according to the flustuation-
]>> dissipation theorem.
]
]And this random noise produces "jitter" which is normally-distributed,
]tiny, bipolar, and independent on a cycle-by-cycle basis. This
]affects the "bandwidth" of the signal, not frequency measurements
]which cover many cycles of operation.
As I pointed out before, you need some remedial reading on the
statistical physics. Try Feinman's lectures about mathematics
of brownian walk. May be, you'll understand that what you
write is incorrect.
]
]>The reason a resistor produces the
]>> thermal noise is that same theorem.
]
]And do resistors also "drift"? It is the same theorem, after all....
You must be trying to crack me up, Mr.Ritter. Good thing I wasn't
drinking coffee.
]>I am also pointing out that this
]>> thermal noise will lead to brownian-walk drift of the clock which
]>> can be measured to produce truly unpredictable random data.
]
]I am aware of no publication which suggests a "brownian-walk" from
]crystal noise. That simply does not happen. Jitter is bipolar and
]cycle-by-cycle independent.
So is motion of brownian particle. Yet the average square of the
position grows linearly with time (provided it starts from
the origin).
]>>So far,
]>> you and others went on all sorts of tangents due to the failure
]>> to understand what I am saying.
]
]What you claim either does not occur in quartz crystal oscillators at
]all, or does not occur at sensible levels.
]
]
]>It may LOOK like a Brownian drift, but is it?
]
]I doubt it even looks like it.
]
]>Brownian drift
]>actually has infinite energy,
I have no idea what this is supposed to mean.
] so what one has is at best an
]>approximation. Also, a slowly varying drift, easily possible
]>with thermal effects of any kind, can play much havoc with
]>using such a device to obtain supposedly random output.
See my earlier post that mentions renormalization of clock
frequency.
]>Even radioactive counts, already digital and with excellent
]>independence properties, cannot be used as such, because of
]>both dead time, and the biases introduced by the analog
]>nature of the counter-data interface. This latter one is
]>particularly bad, and will apply to anything used directly.
]
]
]I claim the proposed effect simply does not exist at sensible levels.
That's because you lack very basic understanding of the statistics
of Brownian random walk.
]I suppose if one measures anything precisely enough one will run into
]randomness. But there are other sources of variation, in particular
]ambient temperature; we will not be measuring crystal jitter on our
]unmodified PC's.
------------------------------
** 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
******************************
