Re: Challenge to TCPA/Palladium detractors

2002-08-10 Thread lynn . wheeler
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 propor

Re: Challenge to TCPA/Palladium detractors

2002-08-10 Thread lynn . wheeler
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 slight

Re: Challenge to TCPA/Palladium detractors

2002-08-10 Thread Russell Nelson
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 >

Re: Re: Challenge to TCPA/Palladium detractors

2002-08-10 Thread Joseph Ashwood
- 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 s

Re: Challenge to TCPA/Palladium detractors

2002-08-10 Thread Eugen Leitl
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: Challenge to TCPA/Palladium detractors

2002-08-10 Thread R. Hirschfeld
> 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

Re: Challenge to TCPA/Palladium detractors

2002-08-09 Thread AARG! Anonymous
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

Re: Challenge to TCPA/Palladium detractors

2002-08-09 Thread Ken Brown
"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 comp

RE: Challenge to TCPA/Palladium detractors

2002-08-09 Thread Sam Simpson
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 Offi

Re: Challenge to TCPA/Palladium detractors

2002-08-09 Thread Eugen Leitl
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, eve

Re: Challenge to TCPA/Palladium detractors

2002-08-09 Thread David Howe
> Same version of compiler on same source using same build produces > identical binaries. 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 w

Re: Challenge to TCPA/Palladium detractors

2002-08-09 Thread Eugen Leitl
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

RE: Challenge to TCPA/Palladium detractors

2002-08-09 Thread Lucky Green
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

Re: Challenge to TCPA/Palladium detractors

2002-08-08 Thread AARG! Anonymous
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 signatur

Re: Challenge to TCPA/Palladium detractors

2002-08-08 Thread R. Hirschfeld
> 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: >

Re: Challenge to TCPA/Palladium detractors

2002-08-08 Thread Matt Crawford
> 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 impo

Re: Challenge to TCPA/Palladium detractors

2002-08-08 Thread R. Hirschfeld
> 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