On 10/13/06, Kuehn, Ulrich <[EMAIL PROTECTED]> wrote:
With reliably stopping the boot process I mean the following: Given that
stage i of the process is running, it takes the hash of the next stage,
compares that to an expected value. If they match, the current stage extends
the TPM register (whe
Here is a posting from the cypherpunks mailing list describing the
capabilities of Intel's new virtualization/TPM technology. Gets a bit
ranty but still good information.
CP
-- Forwarded message --
From: "Anonymous Remailer (austria)" <[EMAIL PROTECTED]>
Date: Fri, 29 Sep 2006 03
On 10/10/06, Adam Back <[EMAIL PROTECTED]> wrote:
I think the current CPUs / memory managers do not have the ring -1 /
curtained memory features, but already a year ago or more Intel and
AMD were talking about these features. So its possible the for
example hypervisor extra virtualization functi
On 10/10/06, Brian Gladman <[EMAIL PROTECTED]> wrote:
I haven't been keeping up to date with this trusted computing stuff over
the last two years but when I was last involved it was accepted that it
was vital that the owner of a machine (not necessarily the user) should
be able to do the sort of
> WASHINGTON--Quantum computers don't exist outside the laboratory. But the
> U.S. government appears to be exploring whether it should be illegal to
> ship them overseas.
>
> A federal advisory committee met Wednesday to hear an IBM presentation
> about just how advanced quantum computers hav
On 11/4/05, Travis H. <[EMAIL PROTECTED]> wrote:
> By my calculations, it looks like you could take a keypair n,e,d and
> some integer x and let e'=e^x and d'=d^x, and RSA would still work,
> albeit slowly. Reminds me of blinding, to some extent, except we're
> working with key material and not pl
On 11/6/05, Travis H. <[EMAIL PROTECTED]> wrote:
> Personally, I'm less suprised by my own software (and, presumably,
> key-handling) than vendor software, most of the time. I think TCPA is
> about control, and call me paranoid, but ultimate control isn't
> something I'm willing to concede to any
On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> The system works this way: Each WiKID domain now can include a
> 'registered URL' field and a hash that website's SSL certificate. When
> a user wants to log onto a secure web site, they start the WiKID token
> and enter their PIN. The PIN is enc
On 10/30/05, Arash Partow <[EMAIL PROTECTED]> wrote:
> How does one properly use a symmetric cipher as a cryptographic hash
> function? I seem to be going around in circles.
The usual method is to feed the data into the "key" slot of the
cipher, and to use a fixed IV in the "plaintext" slot. Then,
On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> cyphrpunk wrote:
> > On 10/31/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> >
> >>The system works this way: Each WiKID domain now can include a
> >>'registered URL' field and a hash that websit
On 11/3/05, Nick Owen <[EMAIL PROTECTED]> wrote:
> The token client pulls down a hash of the certificate from the
> WiKID server. It pulls the certificate from the website and performs a
> hash on it. It compares the two hashes and if they match, presents the
> user with the OTP and the message:
>
On 10/31/05, Kuehn, Ulrich <[EMAIL PROTECTED]> wrote:
> There are results available on this issue: First, a paper by
> Boneh, Joux, and Nguyen "Why Textbook ElGamal and RSA Encryption
> are Insecure", showing that you can essentially half the number
> of bits in the message, i.e. in this case the s
On 10/28/05, Daniel A. Nagy <[EMAIL PROTECTED]> wrote:
> Irreversibility of transactions hinges on two features of the proposed
> systetm: the fundamentally irreversible nature of publishing information in
> the public records and the fact that in order to invalidate a secret, one
> needs to know i
One other point with regard to Daniel Nagy's paper at
http://www.epointsystem.org/~nagydani/ICETE2005.pdf
A good way to organize papers like this is to first present the
desired properties of systems like yours (and optionally show that
other systems fail to meet one or more of these properties);
On 10/26/05, James A. Donald <[EMAIL PROTECTED]> wrote:
> How does one inflate a key?
Just make it bigger by adding redundancy and padding, before you
encrypt it and store it on your disk. That way the attacker who wants
to steal your keyring sees a 4 GB encrypted file which actually holds
about a
Wasn't there a rumor last year that Skype didn't do any encryption
padding, it just did a straight exponentiation of the plaintext?
Would that be safe, if as the report suggests, the data being
encrypted is 128 random bits (and assuming the encryption exponent is
considerably bigger than 3)? Seems
On 10/25/05, Travis H. <[EMAIL PROTECTED]> wrote:
> More on topic, I recently heard about a scam involving differential
> reversibility between two remote payment systems. The fraudster sends
> you an email asking you to make a Western Union payment to a third
> party, and deposits the requested a
> http://www.hbarel.com/Blog/entry0006.html
>
> I believe that for anonymity and pseudonymity technologies to survive
> they have to be applied to applications that require them by design,
> rather than to mass-market applications that can also do (cheaper)
> without. If anonymity mechanisms a
On 10/24/05, John Kelsey <[EMAIL PROTECTED]> wrote:
> More to the point, an irreversible payment system raises big practical
> problems in a world full of very hard-to-secure PCs running the
> relevant software. One exploitable software bug, properly used, can
> steal an enormous amount of money i
On 10/24/05, Steve Schear <[EMAIL PROTECTED]> wrote:
> I don't think E-gold ever held out its system as non-reversible with proper
> court order. All reverses I am aware happened either due to some technical
> problem with their system or an order from a court of competence in the
> matter at hand
On 10/22/05, Ian G <[EMAIL PROTECTED]> wrote:
> R. Hirschfeld wrote:
> > This is not strictly correct. The payer can reveal the blinding
> > factor, making the payment traceable. I believe Chaum deliberately
> > chose for one-way untraceability (untraceable by the payee but not by
> > the payer)
On 10/23/05, Travis H. <[EMAIL PROTECTED]> wrote:
> My understanding of the peer-to-peer key agreement protocol (hereafter
> p2pka) is based on section 3.3 and 3.4.2 and is something like this:
>
> A -> B: N_ab
> B -> A: N_ba
> B -> A: Sign{f(N_ab)}_a
> A -> B: Sign{f(N_ba)}_b
> A -> B: Sign{A, K_a
On 10/20/05, Daniel A. Nagy <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 20, 2005 at 03:36:54PM -0700, cyphrpunk wrote:
> > As far as the issue of receipts in Chaumian ecash, there have been a
> > couple of approaches discussed.
> >
> > The simplest goes like this. If
As far as the issue of receipts in Chaumian ecash, there have been a
couple of approaches discussed.
The simplest goes like this. If Alice will pay Bob, Bob supplies Alice
with a blinded proto-coin, along with a signed statement, "I will
perform service X if Alice supplies me with a mint signature
Let's take a look at Daniel Nagy's list of desirable features for an
ecash system and see how simple, on-line Chaum ecash fares.
> http://www.epointsystem.org/~nagydani/ICETE2005.pdf
>
> One of the reasons, in the author s opinion, is that payment systems
> based on similar schemes lack some ke
On 10/19/05, Daniel A. Nagy <[EMAIL PROTECTED]> wrote:
> > > http://www.epointsystem.org/~nagydani/ICETE2005.pdf
>
> Note that nowhere in my paper did I imply that the issuer is a bank (the
> only mentioning of a bank in the paper is in an analogy). This is because I
> am strongly convinced that b
> Just presented at ICETE2005 by Daniel Nagy:
>
> http://www.epointsystem.org/~nagydani/ICETE2005.pdf
>
> Abstract. In present paper a novel approach to on-line payment is
> presented that tackles some issues of digital cash that have, in the
> author s opinion, contributed to the fact that d
On 10/3/05, Jason Holt <[EMAIL PROTECTED]> wrote:
>
> More thoughts regarding the tokens vs. certs decision, and also multi-use:
This is a good summary of the issues. With regard to turning client
certs on and off: from many years of experience with anonymous and
pseudonymous communication, the bi
On 10/1/05, Jason Holt <[EMAIL PROTECTED]> wrote:
> The reason I have separate token and cert servers is that I want to end up
> with a client cert that can be used in unmodified browsers and servers. The
> certs don't have to have personal information in them, but with indirection we
> cheaply ge
A few comments on the implementation details of
http://www.lunkwill.org/src/nym/:
1. Limting token requests by IP doesn't work in today's internet. Most
customers have dynamic IPs. Either they won't be able to get tokens,
because someone else has already gotten one using their temporary IP,
or the
On 9/30/05, Jason Holt <[EMAIL PROTECTED]> wrote:
> http://www.lunkwill.org/src/nym/
> ...
> My proposal for using this to enable tor users to play at Wikipedia is as
> follows:
>
> 1. Install a token server on a public IP. The token server can optionally be
> provided Wikipedia's blocked-IP list
31 matches
Mail list logo
