Re: Challenge to TCPA/Palladium detractors
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.
Re: CDR: Re: Challenge to TCPA/Palladium detractors
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 such that no one can get access to the data outside the limitations and rules imposed by the applications. Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. Complete noise. Not only can it be done, it is being done. Plan 9 has a namespace that is -per processs-, each process is distributed (via a bidding process), and the process owner can be anonymized (though this takes some extension beyond the base OS). http://plan9.bell-labs.com -- Conform and be dull..J. Frank Dobie [EMAIL PROTECTED] www.ssz.com [EMAIL PROTECTED] www.open-forge.org
Re: Re: Challenge to TCPA/Palladium detractors
- 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 semi-random exploration. Because of this random exploration the compiler will typically compile the same code into a different executable. With small programs it is likely to find the same end-point, because of the simplicity. The larger the program the more points for optimization, so for something as large as say PGP you are unlikely to find the same point twice, however the performance is likely to be eerily similar. There are bound to be exceptions, and sometimes the randomness in the exploration appears non-existent, but I've been told that some versions the DEC GEM compiler used semi-randomness a surprising amount because it was a very fast way to narrow down to an approximate best (hence the extremely fast compilation and execution). It is likely that MS VC uses such techniques. Oddly extremely high level languages don't have as many issues, each command spans so many instructions that a pretuned set of command instructions will often provide very close to optimal performance. I've been told that gcc does not apparently use randomness to any significant degree, but I admit I have not examined the source code to confirm or deny this. Joe
Re: Challenge to TCPA/Palladium detractors
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 the limitations and rules imposed by the applications. Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. You have failed to specify that the cost of breaking into the data has to exceed the value of the data. But even if you did that, you'd have to assume that the data was never worth more than that to *anyone*. As soon as it was worth that, they could break into the data, and data is, after all, just data. Ignore economics at your peril. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: Challenge to TCPA/Palladium detractors
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 that is loaded into memory. For Palladium it is just the part of the program called the trusted agent. So file headers with dates, compiler version numbers, etc., will not be part of the data which is hashed. The only thing that would really break the hash would be changes to the compiler code generator that cause it to create different executable output for the same input. This might happen between versions, but probably most widely used compilers are relatively stable in that respect these days. Specifying the compiler version and build flags should provide good reliability for having the executable content hash the same way for everyone. A trivial observation: this cannot be true across hardware platforms. TCPA claims to be platform and OS agnostic, but Palladium does not.
Re: Challenge to TCPA/Palladium detractors
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.
Re: Re: Challenge to TCPA/Palladium detractors
- 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 semi-random exploration. Because of this random exploration the compiler will typically compile the same code into a different executable. With small programs it is likely to find the same end-point, because of the simplicity. The larger the program the more points for optimization, so for something as large as say PGP you are unlikely to find the same point twice, however the performance is likely to be eerily similar. There are bound to be exceptions, and sometimes the randomness in the exploration appears non-existent, but I've been told that some versions the DEC GEM compiler used semi-randomness a surprising amount because it was a very fast way to narrow down to an approximate best (hence the extremely fast compilation and execution). It is likely that MS VC uses such techniques. Oddly extremely high level languages don't have as many issues, each command spans so many instructions that a pretuned set of command instructions will often provide very close to optimal performance. I've been told that gcc does not apparently use randomness to any significant degree, but I admit I have not examined the source code to confirm or deny this. Joe
Re: Challenge to TCPA/Palladium detractors
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 the limitations and rules imposed by the applications. Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. You have failed to specify that the cost of breaking into the data has to exceed the value of the data. But even if you did that, you'd have to assume that the data was never worth more than that to *anyone*. As soon as it was worth that, they could break into the data, and data is, after all, just data. Ignore economics at your peril. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX |
Re: Challenge to TCPA/Palladium detractors
small discussion of security proportional to risk: http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk slightly related http://www.garlic.com/~lynn/2001j.html#5 E-commerce security http://www.garlic.com/~lynn/2001j.html#54 Does Strong Security Mean Anything? also slightly related, both the tpm chips and various card chips are similar ... some with eal3-high or eal4-high evaluation. however these ratings are typically just for the chip ... or the chip with the barest of software not the completely delivered operation environment. trying to get an EAL5-high or EAL6-high on the complete package would include getting evaluation on things like any crypto (for those chips employing crypto) ... which is a interesting whole 'nother exercise. slightly related: http://www.garlic.com/~lynn/aadsm12.htm#13 anybody seen (EAL5) semi-formal specification for FIPS186-2/x9.62 ecdsa? http://www.garlic.com/~lynn/2002h.html#71 history of CMS http://www.garlic.com/~lynn/2002h.html#84 history of CMS http://www.garlic.com/~lynn/2002j.html#86 formal fips186-2/x9.62 definition for eal 5/6 evaluation [EMAIL PROTECTED] on 8/10/2002 11:01 pm wrote: Can't be done. I don't have time to go into ALL the reasons. Fortunately for me, any one reason is sufficient. #1: it's all about the economics. You have failed to specify that the cost of breaking into the data has to exceed the value of the data. But even if you did that, you'd have to assume that the data was never worth more than that to *anyone*. As soon as it was worth that, they could break into the data, and data is, after all, just data. Ignore economics at your peril. -- -russ nelson http://russnelson.com | Crynwr sells support for free software | PGPok | businesses persuade 521 Pleasant Valley Rd. | +1 315 268 1925 voice | governments coerce Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Challenge to TCPA/Palladium detractors
oops, finger slip that should be http://www.garlic.com/~lynn/2001h.html#61 security proportional to risk aka 2001h.html not 2002h.html [EMAIL PROTECTED] on 8/10/2002 11:25 pm wrote: small discussion of security proportional to risk: http://www.garlic.com/~lynn/2002h.html#61 security proportional to risk
Re: Challenge to TCPA/Palladium detractors
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 that is loaded into memory. For Palladium it is just the part of the program called the trusted agent. So file headers with dates, compiler version numbers, etc., will not be part of the data which is hashed. The only thing that would really break the hash would be changes to the compiler code generator that cause it to create different executable output for the same input. This might happen between versions, but probably most widely used compilers are relatively stable in that respect these days. Specifying the compiler version and build flags should provide good reliability for having the executable content hash the same way for everyone. A trivial observation: this cannot be true across hardware platforms. TCPA claims to be platform and OS agnostic, but Palladium does not.
RE: Challenge to TCPA/Palladium detractors
Anonymous wrote: Matt Crawford replied: Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green
Re: Challenge to TCPA/Palladium detractors
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 the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. You have the source, compile it using the official compiler and the official build options, and record the blob. Entity X claims it runs the same system that it gave you the source for. You can't sign it, but you can verify the signed blob is the same. The blob can still be trojaned, but you can disassemble and debug it.
Re: Challenge to TCPA/Palladium detractors
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 if you hit rebuild all twice in close succession and compare the two outputs, nothing having changed. I've just verified this also occurs on OpenSSL under RH 7.3 (gcc --version 2.96). I haven't done a binary diff, but I'm also suspecting a time stamp. Can anyone shed some light on this?
Re: Challenge to TCPA/Palladium detractors
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 source using same build produces identical binaries. This has not been my experience. Nor anyone else's If only because the exact image you depends on a hell of a lot of programs libraries. Does anyone expect /Microsoft/ of all software suppliers to provide consistent versioning and reproducible or predictable software environments? These are the people who brought us DLL Hell. These are the people who fell into the MDAC versioning fiasco. Ken
RE: Challenge to TCPA/Palladium detractors
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 Office: +44 (0) 1438 229390 Fax: +44 (0) 1438 726069 On Fri, 9 Aug 2002, Lucky Green wrote: Anonymous wrote: Matt Crawford replied: Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Challenge to TCPA/Palladium detractors
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 that is loaded into memory. For Palladium it is just the part of the program called the trusted agent. So file headers with dates, compiler version numbers, etc., will not be part of the data which is hashed. The only thing that would really break the hash would be changes to the compiler code generator that cause it to create different executable output for the same input. This might happen between versions, but probably most widely used compilers are relatively stable in that respect these days. Specifying the compiler version and build flags should provide good reliability for having the executable content hash the same way for everyone.
Re: Challenge to TCPA/Palladium detractors
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 the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. You have the source, compile it using the official compiler and the official build options, and record the blob. Entity X claims it runs the same system that it gave you the source for. You can't sign it, but you can verify the signed blob is the same. The blob can still be trojaned, but you can disassemble and debug it.
Re: Challenge to TCPA/Palladium detractors
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 if you hit rebuild all twice in close succession and compare the two outputs, nothing having changed. I've just verified this also occurs on OpenSSL under RH 7.3 (gcc --version 2.96). I haven't done a binary diff, but I'm also suspecting a time stamp. Can anyone shed some light on this?
Re: Challenge to TCPA/Palladium detractors
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 source using same build produces identical binaries. This has not been my experience. Nor anyone else's If only because the exact image you depends on a hell of a lot of programs libraries. Does anyone expect /Microsoft/ of all software suppliers to provide consistent versioning and reproducible or predictable software environments? These are the people who brought us DLL Hell. These are the people who fell into the MDAC versioning fiasco. Ken
RE: Challenge to TCPA/Palladium detractors
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 Office: +44 (0) 1438 229390 Fax: +44 (0) 1438 726069 On Fri, 9 Aug 2002, Lucky Green wrote: Anonymous wrote: Matt Crawford replied: Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI The above view may be overly optimistic. IIRC, nobody outside PGP was ever able to compile a PGP binary from source that matched the hash of the binaries built by PGP. --Lucky Green - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Challenge to TCPA/Palladium detractors
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 such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others?
Re: Challenge to TCPA/Palladium detractors
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 by the applications. [...] 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. Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code.
Re: Challenge to TCPA/Palladium detractors
Date: Thu, 8 Aug 2002 21:55:40 +0200 From: R. Hirschfeld [EMAIL PROTECTED] 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 such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others? Sorry, I see from an earlier message of yours that you are looking for a simple non-crypto solution, so I guess this doesn't fit the bill. The examples you gave in your earlier message all seem to be equivalent to having the participants send the data to a trusted third party who performs the computation, except that the trusted third party is transplanted to one or more of the participants computers, which are protected against their owners. I guess it boils down to whether or not the level of trust is sufficient. This seems iffy when one of the participants is also the trust provider.
Re: Challenge to TCPA/Palladium detractors
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 the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI
Re: Challenge to TCPA/Palladium detractors
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 such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others?
Re: Challenge to TCPA/Palladium detractors
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 by the applications. [...] 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. Unless the application author can predict the exact output of the compilers, he can't issue a signature on the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code.
Re: Challenge to TCPA/Palladium detractors
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 the object code. The compilers then have to be inside the trusted base, checking a signature on the source code and reflecting it somehow through a signature they create for the object code. It's likely that only a limited number of compiler configurations would be in common use, and signatures on the executables produced by each of those could be provided. Then all the app writer has to do is to tell people, get compiler version so-and-so and compile with that, and your object will match the hash my app looks for. DEI
Re: Challenge to TCPA/Palladium detractors
Date: Thu, 8 Aug 2002 21:55:40 +0200 From: R. Hirschfeld [EMAIL PROTECTED] 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 such that no one can get access to the data outside the limitations and rules imposed by the applications. The model and the goal are a bit different, but how about secure multi-party computation, as introduced by Chaum, Crepeau, and Damgard in 1988 and subsequently refined by others? Sorry, I see from an earlier message of yours that you are looking for a simple non-crypto solution, so I guess this doesn't fit the bill. The examples you gave in your earlier message all seem to be equivalent to having the participants send the data to a trusted third party who performs the computation, except that the trusted third party is transplanted to one or more of the participants computers, which are protected against their owners. I guess it boils down to whether or not the level of trust is sufficient. This seems iffy when one of the participants is also the trust provider.
