hat's
holding back Linux IPSEC.
IMHO: If Freeswan had never been created, an alternate, more mature implementation
would already exist in the mainline Linux kernel.
--Anonymous
-
The Cryptography Mailing List
Unsubscribe
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
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 1
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
Paul Crowley writes:
> Silverman is AFAICT the most knowledgeable person to have commented on
> all this. He has no axe to grind, unless you count the inexcusably
> unfair treatment he received from RSA.
>
> All of his sci.crypt comments are available with this search:
>
> http://groups.google.c
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 gai
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 number
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 ge
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 a
[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, PU
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 explic
the current "K" in use by Alice and
Bob's session, she cannot impersonate either of them? Or does it mean
something else?
Can someone better explain how the "forward security" found in
EKE/DH-EKE/SPEKE works? Is it the same for each EKE variant, or does it
> 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
Seth Schoen writes:
> The Palladium security model and features are different from Unix, but
> you can imagine by rough analogy a Unix implementation on a system
> with protected memory. Every process can have its own virtual memory
> space, read and write files, interact with the user, etc. But
eculate that anonymity is being used to disguise some vested
> interest in supporting TCPA. In other words, I infer that Mr. AARGH!
> is a TCPA insider, who is embarassed to reveal himself in public.
>
> So my question is: What is your reason for shielding your identity?
> You do so
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
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 therefor
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 hav
system with anonymity.
Again, there are many cryptographic systems in the literature for
anonymous communication. But they tend to be complicated and inefficient.
With TCPA we only need to set up a simple flooding broadcast network.
Let each peer connect to a few other peers. To prevent tra
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
Seth Schoen writes:
> There is
> a much larger conversation about trusted computing in general, which
> we ought to be having:
>
> What would make you want to enter sensitive information into a
> complicated device, built by people you don't know, which you can't
> take apart under a microscope?
An article on Salon this morning (also being discussed on slashdot),
http://www.salon.com/tech/feature/2002/08/08/gnutella_developers/print.html,
discusses how the file-trading network Gnutella is being threatened by
misbehaving clients. In response, the developers are looking at limiting
the net
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 th
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 pictur
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
some advantage from having a broad industry initiative. Our fundamental
goal is "let's do the right thing." We have pretty strong feelings about
what the right thing is on terms of making sure that things are truly
anonymous and that key escrow kinds of things don't happen. B
the published facts, and
> they couldn't impugn the credentials of the authors, nor the
> document's internal reasoning.
I agree in principle, but I am appalled that you believe that Lucky in
particular is heading in the right direction. Adam on the other hand
has at least begun to
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 compa
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 Lis
In discussing how TCPA would help enforce a document revocation list
(DRL) Joseph Ashwood contrasted the situation with and without TCPA
style hardware, below. I just want to point out that his analysis of
the hardware vs software situation says nothing about DRL's specifically;
in fact it doesn'
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 state
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
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 would be good to consider how exactly that
problem could be eliminate
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 wh
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 t
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 eigen
38 matches
Mail list logo
