Good presentation. I liked the boot diagrams quite a bit.
Prediction (and remember you heard it here first): TCPA will fail. Oh it'll
see some spot uses, don't get me wrong. These spot uses might even remain
for a while. But the good thing is that Microsoft is probably going to have
to carry
it already, but a TCPA chip might do it better).
So a question for the TCPA proponents (or opponents):
how would I do that using TCPA?
Eric
At 4:18 PM -0400 6/29/04, An Metet wrote:
On August 6, 2002, Lucky Green wrote a reply to Anonymous (whom I will
now come clean and admit was none other than me)
Prove it.
;-)
Cheers,
RAH
--
-
R. A. Hettinga mailto: [EMAIL PROTECTED]
The Internet Bearer Underwriting
On August 6, 2002, Lucky Green wrote a reply to Anonymous (whom I will
now come clean and admit was none other than me), about the suggestion
that TCPA (now called TCG) could incorporate anonymous cryptographic
credentials to protect users' privacy, rather than the cumbersome
privacy CA mechanism
will
make this process more difficult. To the extend that Palladium/TCPA/NGSCB
hides code, and to the extent it succeeds at this hiding, the more it
encourages new and more pervasive viruses.
Cheers - Bill
-
Bill Frantz
be talking about biology as well.
Any system which hides code from reverse engineering will
make this process more difficult. To the extend that
Palladium/TCPA/NGSCB
hides code, and to the extent it succeeds at this hiding, the more it
encourages new and more pervasive viruses.
A virus that contains
On Thu, Oct 23, 2003 at 11:59:47AM -0700, Major Variola (ret) wrote:
And virii that infect the immune system can be fun too --imagine a virus
infecting your antiviral program. HIV for Windows.
Or a virus that modifes your other programs to make them appear to
be known virii. You'd have to
On Sun, Feb 09, 2003 at 02:32:13PM -0800, Mike Rosing wrote:
TPM != TCPA. TCPA with *user* control is good.
The TPM is a mandatory part of the TCPA specifications.
There will be no TCPA without TPM.
And there will be no TCPA-enabled system with complete user control.
Just look at the main
On Tue, 11 Feb 2003, Michel Messerschmidt wrote:
The TPM is a mandatory part of the TCPA specifications.
There will be no TCPA without TPM.
That makes sense, TPM is just key storage.
And there will be no TCPA-enabled system with complete user control.
Just look at the main specification
On Sun, 9 Feb 2003, Anonymous via the Cypherpunks Tonga Remailer wrote:
However note: you can't defend TCPA as being good vs Palladium bad
(as you did by in an earlier post) by saying that TCPA only provides
key storage.
TPM != TCPA. TCPA with *user* control is good.
As Michel noted TCPA
On Wed, Feb 05, 2003 at 07:15:50AM -0800, Mike Rosing wrote:
On Tue, 4 Feb 2003, AARG! Anonymous wrote:
The main features of TCPA are:
- key storage
The IBM TPM does this part.
AFAIK, IBM's embedded security subsystem 1.0 is only a key
storage device (Atmel AT90SP0801 chip
On Sat, 8 Feb 2003, Michel Messerschmidt wrote:
AFAIK, IBM's embedded security subsystem 1.0 is only a key
storage device (Atmel AT90SP0801 chip).
But the TPM we're talking about is part of the TCPA compliant
embedded security subsystem 2.0 which supports all specified
TPM functions, even
, they only know the card is held by the
correct user.
A key store chip could be useful for some applications.
However note: you can't defend TCPA as being good vs Palladium bad
(as you did by in an earlier post) by saying that TCPA only provides
key storage.
As Michel noted TCPA and Palladium both
Mike Rosing wrote:
- secure boot
- sealing
- remote attestation
It does *not* do these parts.
I think you may have been mislead by the slant of paper.
Quoting from the paper:
http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf
you will see:
| The TCPA chip is not particularly suited
On Thu, 6 Feb 2003, Anonymous via the Cypherpunks Tonga Remailer wrote:
I think you may have been mislead by the slant of paper.
Quoting from the paper:
http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf
you will see:
| The TCPA chip is not particularly suited to DRM. While it does have
On Tue, 4 Feb 2003, AARG! Anonymous wrote:
The main features of TCPA are:
- key storage
The IBM TPM does this part.
- secure boot
- sealing
- remote attestation
It does *not* do these parts. That's why IBM wants the TPM != TCPA
to be loud and clear. That's why the RIAA can't expect
at Friday, January 31, 2003 2:18 AM, Peter Gutmann
[EMAIL PROTECTED] was seen to say:
schnipp
More particularly, governments are likely to want to explore the
issues related to potential foreign control/influence over domestic
governmental use/access to domestic government held data.
In
I have seen this *five* times already - is there some sort of wierd mailing
loop in action?
I am fairly certain I haven't sent it five times spread out over two
days
-- Forwarded message --
Date: Fri, 24 Jan 2003 02:29:27 -0500
From: Dave Farber [EMAIL PROTECTED]
To: ip [EMAIL PROTECTED]
Subject: [IP] Open Source TCPA driver and white papers
-- Forwarded Message
From: David Safford [EMAIL PROTECTED]
Date: Tue, 21 Jan 2003 12:05:39 -0500
On Fri, 24 Jan 2003, Eugen Leitl wrote:
-- Forwarded message --
Date: Fri, 24 Jan 2003 02:29:27 -0500
From: Dave Farber [EMAIL PROTECTED]
To: ip [EMAIL PROTECTED]
Subject: [IP] Open Source TCPA driver and white papers
-- Forwarded Message
From: David Safford [EMAIL
at Friday, January 24, 2003 4:53 PM, Mike Rosing [EMAIL PROTECTED]
was seen to say:
Thanks Eugen, It looks like the IBM TPM chip is only a key
store read/write device. It has no code space for the kind of
security discussed in the TCPA. The user still controls the machine
and can still
On Fri, 24 Jan 2003, David Howe wrote:
Bearing in mind though that DRM/Paladium won't work at all if it can't
trust its hardware - so TPM != Paladium, but TPM (or an improved TPM) is
a prerequisite.
Certainly! But this TPM is really nothing more than a dongle
attached to the pci bus. It
Nomen Nescio wrote:
It looks like Camenisch Lysyanskaya are patenting their credential
system. This is from the online patent applications database:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/ne
It looks like Camenisch Lysyanskaya are patenting their credential
system. This is from the online patent applications database:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=/netahtml/PTO/search-bool.htmlr=1f=Gl=50co1=ANDd=PG01s1=camenischOS=camenischRS=camenisch
On Mon, 2 Sep 2002, Nomen Nescio wrote:
It looks like Camenisch Lysyanskaya are patenting their credential
system. This is from the online patent applications database:
Carl Ellison suggested an alternate way that TCPA could work to allow
for revoking virtualized TPMs without the privacy problems associated
with the present systems, and the technical problems of the elaborate
cryptographic methods.
Consider first the simplest possible method, which is just
At 12:58 AM 08/11/2002 -0700, Lucky Green wrote:
BTW, does anybody here know if there is still an email time stamping
server in operation? The references that I found to such servers appear
to be dead.
The canonical timestamping system was Haber Stornetta's work at
Bellcore, commercialized at
:09PM -0700, AARG!Anonymous wrote:
Here are some more thoughts on how cryptography could be used to
enhance user privacy in a system like TCPA. Even if the TCPA group
is not receptive to these proposals, it would be useful to have an
understanding of the security issues. And the same issues arise
Dr. Mike wrote, patiently, persistently and truthfully:
On Fri, 16 Aug 2002, AARG! Anonymous wrote:
Here are some more thoughts on how cryptography could be used to
enhance user privacy in a system like TCPA. Even if the TCPA group
is not receptive to these proposals, it would be useful
copyrighted content? More likely. Will Microsoft enforce its Pd patents
as strongly as it can? Almost certainly.
Right, I think one of the big issues is whether Microsoft's patents cover
Palladium and TCPA, and whether it will even be possible to make a Linux
version of a trusted computing
On Fri, 16 Aug 2002, AARG! Anonymous wrote:
Here are some more thoughts on how cryptography could be used to
enhance user privacy in a system like TCPA. Even if the TCPA group
is not receptive to these proposals, it would be useful to have an
understanding of the security issues
Here are some more thoughts on how cryptography could be used to
enhance user privacy in a system like TCPA. Even if the TCPA group
is not receptive to these proposals, it would be useful to have an
understanding of the security issues. And the same issues arise in
many other kinds of systems
AARG! Wrote:
It seems that there is (a rather brilliant) way to bypass
TCPA (as spec-ed.) I learned about it from two separate
sources, looks like two independent slightly different hacks
based on the same protocol flaw.
Undoubtedly, more people will figure this out.
Hopefully some
I arrived at that decision over four years ago ... TCPA possibly didn't
decide on it until two years ago. In the assurance session in the TCPA
track at spring 2001 intel developer's conference I claimed my chip was
much more KISS, more secure, and could reasonably meet the TCPA
requirements
and ThinkPad models equipped with the Embedded
Security Subsystem and the new TCPA-compliant Embedded Security Subsystem
2.0. By downloading the software after the systems have been shipped, the
customer can be assured that no unauthorized parties have knowledge of the
keys and pass phrases designated
- Original Message -
From: Ben Laurie [EMAIL PROTECTED]
The important part for this, is that TCPA has no key until it has an
owner,
and the owner can wipe the TCPA at any time. From what I can tell this
was
designed for resale of components, but is perfectly suitable as a point
.
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well. The worst case for
cost of this is to purchase an additional motherboard (IIRC Fry's has them
to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well. The worst case for
cost of this is to purchase an additional motherboard (IIRC Fry's has them
as low as $50), giving
It seems that there is (a rather brilliant) way to bypass TCPA (as spec-ed.) I learned
about it from two separate sources, looks like two independent slightly different
hacks based on the same protocol flaw.
Undoubtedly, more people will figure this out.
It seems wise to suppress the urge
in creating an identity
certificate.
So there are in fact three avenues for FBI et al to go about obtaining
covert access to the closed space formed by TCPA applications:
(A) get one of the hardware manufacturers to sign an endorsement key
generated outside a TPM (or get the endorsement CA's private
[Repost]
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually, this is not true for the endoresement key
for privacy reasons.) All that is required to virtualize
a TPM is an attestation from the privacy CA in creating an identity
certificate.
So there are in fact three avenues for FBI et al to go about obtaining
covert access to the closed space formed by TCPA applications:
(A) get one of the hardware
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually, this is not true for the endoresement key, PUBEK/PRIVEK
identity certifate with the endorsement private key.
How does the CA check the endorsement certificate? If it's by
checking the signature, then finding the manufacturer's private
key is very worthwhile - the entire TCPA for 100's of millions
of computers gets compromised. If it's by matching
at Group Signature schemes;
there is one with efficient revocation being presented at Crypto 02.
These involve a TTP but he can't forge credentials, just link identity
keys to endorsement keys (in TCPA terms). Any system which allows for
revocation must have such linkability, right?
As for Joe
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not
--
On 15 Aug 2002 at 15:26, AARG! Anonymous wrote:
Basically I agree with Adam's analysis. At this point I
think he understands the spec equally as well as I do. He
has a good point about the Privacy CA key being another
security weakness that could break the whole system. It
On Thu, 15 Aug 2002, Anonymous wrote:
[Repost]
Joe Ashwood writes:
Actually that does nothing to stop it. Because of the construction of TCPA,
the private keys are registered _after_ the owner receives the computer,
this is the window of opportunity against that as well.
Actually
Lately on both of these lists there has been quite some discussion about
TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :)
However there is something that is very much worth noting, at least about
TCPA.
There is nothing stopping a virtualized version being created
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At 10:58 PM 8/13/2002 -0700, Joseph Ashwood wrote:
Lately on both of these lists there has been quite some discussion
about TCPA and Palladium, the good, the bad, the ugly, and the
anonymous. :) However there is something that is very much worth
Joseph Ashwood wrote:
Lately on both of these lists there has been quite some discussion about
TCPA and Palladium, the good, the bad, the ugly, and the anonymous. :)
However there is something that is very much worth noting, at least about
TCPA.
There is nothing stopping a virtualized
to discriminate against users who did not use them, or
configured them in given ways.
The remaining features of note being sealing, and integrity metric
based security boot-strapping.
However the remote attestation is clearly the feature that TCPA, and
Microsoft place most value on (it being
be no way for
third parties to discriminate against users who did not use them, or
configured them in given ways.
The remaining features of note being sealing, and integrity metric
based security boot-strapping.
However the remote attestation is clearly the feature that TCPA, and
Microsoft
I need to correct myself.
- Original Message -
From: Joseph Ashwood [EMAIL PROTECTED]
Suspiciously absent though is the requirement for symmetric encryption
(page
4 is easiest to see this). This presents a potential security issue, and
certainly a barrier to its use for
One of the many charges which has been tossed at TCPA is that it will
harm free software. Here is what Ross Anderson writes in the TCPA FAQ
at http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html (question 18):
TCPA will undermine the General Public License (GPL), under which
many free and open
- Original Message -
From: Mike Rosing [EMAIL PROTECTED]
Are you now admitting TCPA is broken?
I freely admit that I haven't made it completely through the TCPA
specification. However it seems to be, at least in effect although not
exactly, a motherboard bound smartcard.
Because
--
On 13 Aug 2002 at 0:05, AARG! Anonymous wrote:
The point is that while this is a form of signed code, it's not
something which gives the TPM control over what OS can boot.
Instead, the VCs are used to report to third party challengers
(on remote systems) what the system
perceptible data onto a machine that doesn't have any DRM
crap.
This is what makes the whole analog hole idea idiotic. Humans are
analog - they can copy the data! To plug the analog hole Hollywood
will have to control every human mind directly.
To me, TCPA only makes sense as a step towards some
Brian LaMacchia writes:
So the complexity isn't in how the keys get initialized on the SCP (hey, it
could be some crazy little hobbit named Mel who runs around to every machine
and puts them in with a magic wand). The complexity is in the keying
infrastructure and the set of signed
James A. Donald [EMAIL PROTECTED] wrote :
--
On 13 Aug 2002 at 0:05, AARG! Anonymous wrote:
The point is that while this is a form of signed code, it's not
something which gives the TPM control over what OS can boot.
Instead, the VCs are used to report to third party challengers
(on
actually it is possible to build chips that generate keys as part of
manufactoring power-on/test (while still in the wafer, and the private key
never, ever exists outside of the chip) ... and be at effectively the same
trust level as any other part of the chip (i.e. hard instruction ROM).
using
David Wagner wrote:
Ben Laurie wrote:
Mike Rosing wrote:
The purpose of TCPA as spec'ed is to remove my control and
make the platform trusted to one entity. That entity has the master
key to the TPM.
Now, if the spec says I can install my own key into the TPM, then yes,
it is a very useful
: James A. Donald [EMAIL PROTECTED]
Date: Tue, 30 Jul 2002 20:51:24 -0700
On 29 Jul 2002 at 15:35, AARG! Anonymous wrote:
both Palladium and TCPA deny that they are designed to restrict
what applications you run. The TPM FAQ at
http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads
is an indication
of bias. I sincerely hope that I misunderstood you.
I believe you did, because if you look at what I actually wrote, I did not
say that bringing up the topic of DRLs is an indication of bias:
The association of TCPA with SNRLs is a perfect example of the bias
Mike Rosing wrote:
The difference is fundamental: I can change every bit of flash in my BIOS.
I can not change *anything* in the TPM. *I* control my BIOS. IF, and
only IF, I can control the TPM will I trust it to extend my trust to
others. The purpose of TCPA as spec'ed is to remove my
as the prime goal rather than ad hoc addons as it is now.
Nobody wants to pay for it tho :-)
In short, while TCPA could increase the effectiveness of global DRLs,
they wouldn't be *that* much more effective. Most users will neither
hack their software nor their hardware, so the hardware doesn't make
On Mon, 12 Aug 2002, AARG! Anonymous wrote:
His analysis actually applies to a wide range of security features,
such as the examples given earlier: secure games, improved P2P,
distributed computing as Adam Back suggested, DRM of course, etc..
TCPA is a potentially very powerful security
AARG!Anonymous [EMAIL PROTECTED] writes:
I don't agree with this distinction. If I use a smart card chip that
has a private key on it that won't come off, is that protecting me from
third parties, or vice versa? If I run a TCPA-enhanced Gnutella that
Who owns the key? If you bought
On Sat, 10 Aug 2002, R. Hirschfeld wrote:
A trivial observation: this cannot be true across hardware platforms.
Untrue, just use a VM. Open Boot Forth would do nicely.
TCPA claims to be platform and OS agnostic, but Palladium does not.
Have fun in that there tarpit.
On Sat, 10 Aug 2002, Russell Nelson wrote:
I agree that it's irrelevant. So why is he trying to argue from
authority (always a fallacy anyway) without *even* having any way to
prove that he is that authority?
What has 'authority' got to do with it? Arguments from authority are
-worthless-.
to un-exist, they would arrange for the server no longer to download
that key, and the document would effectively be deleted, everywhere.
Well, sure. It's certainly how I had always envisioned one might build
a secure Document Revocation List using TCPA or Palladium. I didn't
realize this sort
that the document needed to
un-exist, they would arrange for the server no longer to
download that
key, and the document would effectively be deleted, everywhere.
Well, sure. It's certainly how I had always envisioned one
might build a secure Document Revocation List using TCPA
- Original Message -
From: AARG! Anonymous [EMAIL PROTECTED]
[brief description of Document Revocation List]
Seth's scheme doesn't rely on TCPA/Palladium.
Actually it does, in order to make it valuable. Without a hardware assist,
the attack works like this:
Hack your software (which
On Sun, 11 Aug 2002, Russell Nelson wrote:
AARG!Anonymous writes:
I'd like the Palladium/TCPA critics to offer an alternative proposal
for achieving the following technical goal:
Allow computers separated on the internet to cooperate and share data
and computations
Lucky Green wrote:
Ray wrote:
From: James A. Donald [EMAIL PROTECTED]
Date: Tue, 30 Jul 2002 20:51:24 -0700
On 29 Jul 2002 at 15:35, AARG! Anonymous wrote:
both Palladium and TCPA deny that they are designed to restrict
what applications you run. The TPM FAQ at
http
- Original Message -
From: Eugen Leitl [EMAIL PROTECTED]
Can anyone shed some light on this?
Because of the sophistication of modern processors there are too many
variables too be optimized easily, and doing so can be extremely costly.
Because of this diversity, many compilers use
On 11 Aug 2002, David Wagner wrote:
Ben Laurie wrote:
Mike Rosing wrote:
The purpose of TCPA as spec'ed is to remove my control and
make the platform trusted to one entity. That entity has the master
key to the TPM.
Now, if the spec says I can install my own key into the TPM
AARG! Anonymous wrote:
In fact, you are perfectly correct that Microsoft architectures would
make it easy at any time to implement DRL's or SNRL's. They could do
that tomorrow! They don't need TCPA. So why blame TCPA for this feature?
The relevance should be obvious. Without TCPA/Palladium
Seth Schoen of the EFF has a good blog entry about Palladium and TCPA
at http://vitanuova.loyalty.org/2002-08-09.html. He attended Lucky's
presentation at DEF CON and also sat on the TCPA/Palladium panel at
the USENIX Security Symposium.
Seth has a very balanced perspective on these issues
my BIOS. IF, and
only IF, I can control the TPM will I trust it to extend my trust to
others. The purpose of TCPA as spec'ed is to remove my control and
make the platform trusted to one entity. That entity has the master
key to the TPM.
Now, if the spec says I can install my own key
AARG!Anonymous wrote:
Adam Back writes:
- Palladium is a proposed OS feature-set based on the TCPA hardware
(Microsoft)
Actually there seem to be some hardware differences between TCPA and
Palladium. TCPA relies on a TPM, while Palladium uses some kind of
new CPU mode. Palladium
It reminds me of an even better way for a word processor company to make
money: just scramble all your documents, then demand ONE MILLION DOLLARS
for the keys to decrypt them. The money must be sent to a numbered
Swiss account, and the software checks with a server to find out when
the
AARG!Anonymous writes:
I'd like the Palladium/TCPA critics to offer an alternative proposal
for achieving the following technical goal:
Allow computers separated on the internet to cooperate and share data
and computations such that no one can get access to the data outside
AARG! wrote:
I asked Eric Murray, who knows something about TCPA, what he thought
of some of the more ridiculous claims in Ross Anderson's FAQ (like the
SNRL), and he didn't respond. I believe it is because he is unwilling
to publicly take a position in opposition to such a famous
From: AARG! Anonymous [EMAIL PROTECTED]
Think about it: this one innocuous little box holding the TPME key could
ultimately be the root of trust for the entire world. IMO we should
spare no expense in guarding it and making sure it is used properly.
With enough different interest groups
I asked Eric Murray, who knows something about TCPA, what he thought
of some of the more ridiculous claims in Ross Anderson's FAQ (like the
SNRL), and he didn't respond. I believe it is because he is unwilling
to publicly take a position in opposition to such a famous and respected
figure
-BEGIN PGP SIGNED MESSAGE-
AARG! Anonymous [EMAIL PROTECTED] writes:
Lucky Green wrote:
Ray wrote:
If I buy a lock I expect that by demonstrating ownership I
can get a replacement key or have a locksmith legally open it.
It appears the days when this was true are waning. At
Date: Fri, 9 Aug 2002 19:30:09 -0700
From: AARG!Anonymous [EMAIL PROTECTED]
Re the debate over whether compilers reliably produce identical object
(executable) files:
The measurement and hashing in TCPA/Palladium will probably not be done
on the file itself, but on the executable content
On Wed, 7 Aug 2002, Matt Crawford wrote:
Unless the application author can predict the exact output of the
compilers, he can't issue a signature on the object code. The
Same version of compiler on same source using same build produces
identical binaries.
compilers then have to be inside
On Fri, 9 Aug 2002, David Howe wrote:
It doesn't though - that is the point. I am not sure if it is simply
that there are timestamps in the final executable, but Visual C (to give
a common example, as that is what the windows PGP builds compile with)
will not give an identical binary, even
James A. Donald wrote:
--
On Wed, 7 Aug 2002, Matt Crawford wrote:
Unless the application author can predict the exact output of
the compilers, he can't issue a signature on the object code.
The
On 9 Aug 2002 at 10:48, Eugen Leitl wrote:
Same version of compiler on same
I'm not surprised that most people couldn't produce a matching PGP
executbales - most compilers (irrespective of compiler optimisation
options etc) include a timestamp in the executable.
Regards,
Sam Simpson
[EMAIL PROTECTED]
http://www.samsimpson.com/
Mob: +44 (0) 7866 726060
Home
On Thu, Aug 08, 2002 at 09:15:33PM -0700, Seth David Schoen wrote:
Back in the Clipper days [...] how do we know that this
tamper-resistant chip produced by Mykotronix even implements the
Clipper spec correctly?.
The picture is related but has some extra wrinkles with the
TCPA/Palladium
--
On 9 Aug 2002 at 17:15, AARG! Anonymous wrote:
to understand it you need a true picture of TCPA rather than the
false one which so many cypherpunks have been promoting.
As TCPA is currently vaporware, projections of what it will be,
and how it will be used are judgments
useful and appropriate in
really understanding what TCPA/Palladium are all about. Adam, what do
you think?
Just because you can string words together and form a definition doesn't
make it realizable. Once data is in the clear it can be copied, and no
rules can change that. Either the data
blaming
TCPA for a problem which has always existed and always will exist?
The difference is that *anyone* can see what goes on inside an Intel or
AMD processor. Only the key holder of the TPM can see inside the
protected code space. You can't put back doors into the code now
because the code
Date: Mon, 5 Aug 2002 16:25:26 -0700
From: AARG!Anonymous [EMAIL PROTECTED]
The only way that TCPA will become as popular as you fear is if it really
solves problems for people. Otherwise nobody will pay the extra $25 to
put it in their machine.
Although I support the vote-with-your
Date: Wed, 7 Aug 2002 12:50:29 -0700
From: AARG!Anonymous [EMAIL PROTECTED]
I'd like the Palladium/TCPA critics to offer an alternative proposal
for achieving the following technical goal:
Allow computers separated on the internet to cooperate and share data
and computations
I'd like the Palladium/TCPA critics to offer an alternative proposal
for achieving the following technical goal:
Allow computers separated on the internet to cooperate and share data
and computations such that no one can get access to the data outside
the limitations and rules imposed
Anon wrote:
You could even have each participant compile the program himself,
but still each app can recognize the others on the network and
cooperate with them.
Matt Crawford replied:
Unless the application author can predict the exact output of the
compilers, he can't issue a signature on
1 - 100 of 219 matches
Mail list logo
