Russ Neson writes:
3. Cryptography, and therefore PKI, is meaningless unless you first
define a threat model. In all the messages with this Subject, I've
only see one person even mention threat model. Think about the
varying threat models, and the type of cryptography one would propose
to
Bruce Schneier writes in the April 15, 2002, CRYPTO-GRAM,
http://www.counterpane.com/crypto-gram-0204.html:
But there's no reason to panic, or to dump existing systems. I don't think
Bernstein's announcement has changed anything. Businesses today could
reasonably be content with their
Nicko van Someren writes:
The estimate
of the cost of construction I gave was some hundreds of
millions of dollars, a figure by which I still stand.
But what does that mean, to specify (and stand by) the cost of
construction of a factoring machine, without saying anything about how
fast it
Nicko van Someren writes:
I used the number 10^9 for the factor base size (compared to about
6*10^6 for the break of the 512 bit challenge) and 10^11 for the
weight of the matrix (compared to about 4*10^8 for RSA512). Again
these were guesses and they certainly could be out by an order of
Lucky Green writes:
Given how panels are assembled and the role they fulfill, I thought it
would be understood that when one writes that certain results came out
of a panel that this does not imply that each panelist performed the
same calculations. But rather that that the information gained
Wei Dai writes:
Using a factor base size of 10^9, in the relationship finding phase you
would have to check the smoothness of 2^89 numbers, each around 46 bits
long. (See Frog3's analysis posted at
http://www.mail-archive.com/cryptography%40wasabisystems.com/msg01833.html.
Those numbers
On Tue, 30 Apr 2002 at 17:36:29 -0700, Wei Dai wrote:
On Wed, May 01, 2002 at 01:37:09AM +0200, Anonymous wrote:
For about $200 you can buy a 1000 MIPS CPU, and the memory needed for
sieving is probably another couple of hundred dollars. So call it $500
to get a computer that can sieve
The amazing thing about this discussion is that there are two pieces
of conventional wisdom which people in the cypherpunk/EFF/freedom
communities adhere to, and they are completely contradictory.
The first is that protection of copyright is ultimately impossible.
See the analysis in Schneier
Eugen Leitl writes:
Unfortunately no one can accept in good faith a single word coming out of
Redmond. Biddle has been denying Pd can be used for DRM in presentation
(xref Lucky Green subsequent patent claims to call the bluff), however in
recent (of this week) Focus interview Gates
From: R. Saravanan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Wed, 20 Mar 2002 12:50:51 -0700
Enigmail, a GnuPG plugin for Mozilla which has been under development
for some time, has now reached a state of practical usability with the
Mozilla 0.9.9 release. It allows you to send or
Eric Murray writes:
TCPA (when it isn't turned off) WILL restrict the software that you
can run. Software that has an invalid or missing signature won't be
able to access sensitive data[1]. Meaning that unapproved software
won't work.
[1] TCPAmain_20v1_1a.pdf, section 2.2
We need to
Peter Trei writes:
It's rare enough that when a new anononym appears, we know
that the poster made a considered decision to be anonymous.
The current poster seems to have parachuted in from nowhere,
to argue a specific position on a single topic. It's therefore
reasonable to infer
Peter Trei envisions data recovery in a TCPA world:
HoM: I want to recover my data.
Me: OK: We'll pull the HD, and get the data off it.
HoM: Good - mount it as a secondary HD in my new system.
Me: That isn't going to work now we have TCPA and Palladium.
HoM: Well, what do you have to
example of how the secure attestation features of
TCPA/Palladium can allow a kind of software which would never work today,
software where people trust each other. Let's look at another example,
a P2P system with anonymity.
Again, there are many cryptographic systems in the literature for
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 signature on
Adam Back writes a very thorough analysis of possible consequences of the
amazing power of the TCPA/Palladium model. He is clearly beginning to
get it as far as what this is capable of. There is far more to this
technology than simple DRM applications. In fact Adam has a great idea
for how
I want to follow up on Adam's message because, to be honest, I missed
his point before. I thought he was bringing up the old claim that these
systems would give the TCPA root on your computer.
Instead, Adam is making a new point, which is a good one, but to
understand it you need a true picture
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
and bad
aspects of TCPA, as I think Adam has come close to doing a few times,
then it could be a helpful document.
Intel and Microsoft and anonymous chauvanists can and should criticize
such a document if we write one. That will strengthen it by
eliminating any faulty reasoning or errors
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
Adam Back writes:
+---++
| trusted-agent | user mode |
|space | app space |
|(code ++
| compartment) | supervisor |
| | mode / OS |
+---++
| ring -1 / TOR |
David Wagner wrote:
To respond to your remark about bias: No, bringing up Document Revocation
Lists has nothing to do with bias. It is only right to seek to understand
the risks in advance. I don't understand why you seem to insinuate
that bringing up the topic of Document Revocation Lists
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,
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
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
Bear writes:
In this case you'd need to set up the wires-and-gates model
in the QC for two ciphertext blocks, each attached to an
identical plaintext-recognizer function and attached to the
same key register. Then you set up the entangled state,
and collapse the eigenvector on the
26 matches
Mail list logo
