Anonymous writes in favor of palladium arguing that it is optional, so
all is ok.
On Wed, Jul 13, 2005 at 12:15:21AM -0700, cypherpunk wrote:
This is precisely the security model which has so many people upset:
the system owner (the network admin) is giving up control over his
machine, running
Anonymous writes in favor of palladium arguing that it is optional, so
all is ok.
On Wed, Jul 13, 2005 at 12:15:21AM -0700, cypherpunk wrote:
This is precisely the security model which has so many people upset:
the system owner (the network admin) is giving up control over his
machine, running
On Thu, Jun 02, 2005 at 11:05:30AM +0200, DiSToAGe wrote:
I have read infos that say that audio and video drivers will be in the
trusted chain. If your hardware system is used by an os (i.e. win) on
which you can't create drivers, and only industry signed drivers can be
used you can't bypass
[could you use CPU emulator to bypass these motherboard and CPU based
DRM systems].
Answer: no. They have but private keys inside the DRM hardware, and
signed the corresponding public key with a CA that they control. That
plus some hashing/bootstrapping etc of the startup and some other code
There is a simple protocol for this described in Schneier's Applied
Crypto if you have one handy...
(If I recall the application he illustrates with is: it allows two
people to securely compare salary (which is larger) without either
party divulging their specific salary to each other or to a
There is a simple protocol for this described in Schneier's Applied
Crypto if you have one handy...
(If I recall the application he illustrates with is: it allows two
people to securely compare salary (which is larger) without either
party divulging their specific salary to each other or to a
Ken Meltsner [EMAIL PROTECTED] wrote:
Basically, a way to get around NAT and other router issues for a
peer-to-peer system, mostly seamlessly integrated as a special network
driver. Systems connect to a back end server which relays traffic
between peers on named private networks. Sort of P2P
Ken Meltsner [EMAIL PROTECTED] wrote:
Basically, a way to get around NAT and other router issues for a
peer-to-peer system, mostly seamlessly integrated as a special network
driver. Systems connect to a back end server which relays traffic
between peers on named private networks. Sort of P2P
So PGP are now running a pgp key server which attempts to consilidate
the inforamtion from the existing key servers, but screen it by
ability to receive email at the address.
So they send you an email with a link in it and you go there and it
displays your key userid, keyid, fingerprint and email
So PGP are now running a pgp key server which attempts to consilidate
the inforamtion from the existing key servers, but screen it by
ability to receive email at the address.
So they send you an email with a link in it and you go there and it
displays your key userid, keyid, fingerprint and email
For people interested in ecash / credential tech: Stefan Brands book
on his credential / ecash technology is now downloadable in pdf format
from credentica's web site:
http://www.credentica.com/the_mit_pressbook.php
(previously it was only available in hardcopy, and only parts of the
For people interested in ecash / credential tech: Stefan Brands book
on his credential / ecash technology is now downloadable in pdf format
from credentica's web site:
http://www.credentica.com/the_mit_pressbook.php
(previously it was only available in hardcopy, and only parts of the
I don't know if my info is still current (and I did not read the
article), but the last time I went to the US (early this year) my H1B
was no longer in effect (I quit microsoft last year, and H1B visas are
tied to employer), and I did not get fingerprinted.
However they had a camera and
Hi
I proposed a related algorithm based on time-lock puzzles as a step
towards non-parallelizable, fixed-minting-cost stamps in section 6.1
of [1], also Dingledine et al observe the same in [2].
The non-parallelizable minting function is in fact the reverse: sender
encrypts (expensively) and the
Hi
I proposed a related algorithm based on time-lock puzzles as a step
towards non-parallelizable, fixed-minting-cost stamps in section 6.1
of [1], also Dingledine et al observe the same in [2].
The non-parallelizable minting function is in fact the reverse: sender
encrypts (expensively) and the
(This discussion from hashcash list is Cc'd to cryptography and
cypherpunks.)
Hashcash uses SHA1 and computes a partial pre-image of the all 0bit
string (0^160).
Following is a discussion of what the recent results from Joux, Wang
et al, and Biham et al on SHA0, MD5, SHA1 etc might imply for
Maybe Bin Laden would turn himself in in return for a billion $ for
his cause (through a middle-man of course).
Seem to remember that Bin Laden was relatively wealthy himself (100
M$?), but you'd have to balance these rewards to not be too
excessively much more than net worth of the individual.
The planet sized processor stuff reminds me of Charlie Stross' sci-fi
short story Scratch Monkey which features nanotech, planet sized
processors which colonize space and build more planet-sized
processors. The application is upload, real-time memory backup, and
afterlife in DreamTime
But most cryptanalysis types of things are economic defenses. (ie you
can spend $lots you can break; or you don't have enough $ to build
because the $ at current tech is an astronomical multiple of the US
national debt).
So if the NSA are being stupid, and uneconomical with the black budget
(and
released so it could be
used with the forthcoming i2p IP overlay http://www.i2p.net/ ?
steve
At 01:09 PM 7/7/2004, Adam Back wrote:
Then we implemented a replacement version 2 mail system that I
designed. The design is much simpler. With freedom anonymous
networking you had anyway
released so it could be
used with the forthcoming i2p IP overlay http://www.i2p.net/ ?
steve
At 01:09 PM 7/7/2004, Adam Back wrote:
Then we implemented a replacement version 2 mail system that I
designed. The design is much simpler. With freedom anonymous
networking you had anyway
This is somewhat related to what ZKS did in their version 1 [1,2] mail
system.
They made a transparent local pop proxy (transparent in that it
happened at firewall level, did not have to change your mail client
config). In this case they would talk to your real pop server,
decrypt the parts
Here's a forward of parts of an email I sent to Richard with comments on
his and Ben's paper (sent me a pre-print off-list a couple of weeks ago):
One obvious comment is that the calculations do not take account of
the CAMRAM approach of charging for introductions only. You mention
this in the
Here's a forward of parts of an email I sent to Richard with comments on
his and Ben's paper (sent me a pre-print off-list a couple of weeks ago):
One obvious comment is that the calculations do not take account of
the CAMRAM approach of charging for introductions only. You mention
this in the
On Tue, May 11, 2004 at 09:10:35PM +, Jason Holt wrote:
[...] issue [...] would be how you actually get your certs to the
other guy. Hidden credentials, as Ninghui pointed out, assume you
have some means for creating the other guy's cert,
[...]
The OSBE paper, OTOH, assumes we're going
On Tue, May 11, 2004 at 09:10:35PM +, Jason Holt wrote:
[...] issue [...] would be how you actually get your certs to the
other guy. Hidden credentials, as Ninghui pointed out, assume you
have some means for creating the other guy's cert,
[...]
The OSBE paper, OTOH, assumes we're going
Gap may be I'm misunderstanding something about the HC approach.
We have:
P = (P1 or P2) is encoded HC_E(R,p) = {HC_E(R,P1),HC_E(R,P2)}
so one problem is marking, the server sends you different R values:
{HC_E(R,P1),HC_E(R',P2)}
so you described one way to fix that by using
On Mon, May 10, 2004 at 08:02:12PM +, Jason Holt wrote:
Adam Back wrote:
[...] However the server could mark the encrypted values by encoding
different challenge response values in each of them, right?
Yep, that'd be a problem in that case. In the most recent (unpublished)
paper, I
But if I understand that is only half of the picture. The recipient's
IBE CA will still be able to decrypt, tho the sender's IBE CA may not
as he does not have ability to compute pseudonym private keys for the
other IBE CA.
If you make it PFS, then that changes to the recipient's IBE CA can
get
Gap may be I'm misunderstanding something about the HC approach.
We have:
P = (P1 or P2) is encoded HC_E(R,p) = {HC_E(R,P1),HC_E(R,P2)}
so one problem is marking, the server sends you different R values:
{HC_E(R,P1),HC_E(R',P2)}
so you described one way to fix that by using
On Mon, May 10, 2004 at 02:42:04AM +, Jason Holt wrote:
However can't one achieve the same thing with encryption: eg an SSL
connection and conventional authentication?
How would you use SSL to prove fulfillment without revealing how?
You could get the CA to issue you a patient or
On Mon, May 10, 2004 at 03:03:56AM +, Jason Holt wrote:
[...] Actually, now that you mention Chaum, I'll have to look into
blind signatures with the BF IBE (issuing is just a scalar*point
multiply on a curve).
I think you mean so that the CA/IBE server even though he learns
pseudonyms
On Mon, May 10, 2004 at 02:42:04AM +, Jason Holt wrote:
However can't one achieve the same thing with encryption: eg an SSL
connection and conventional authentication?
How would you use SSL to prove fulfillment without revealing how?
You could get the CA to issue you a patient or
On Mon, May 10, 2004 at 03:03:56AM +, Jason Holt wrote:
[...] Actually, now that you mention Chaum, I'll have to look into
blind signatures with the BF IBE (issuing is just a scalar*point
multiply on a curve).
I think you mean so that the CA/IBE server even though he learns
pseudonyms
On Mon, May 10, 2004 at 08:02:12PM +, Jason Holt wrote:
Adam Back wrote:
[...] However the server could mark the encrypted values by encoding
different challenge response values in each of them, right?
Yep, that'd be a problem in that case. In the most recent (unpublished)
paper, I
But if I understand that is only half of the picture. The recipient's
IBE CA will still be able to decrypt, tho the sender's IBE CA may not
as he does not have ability to compute pseudonym private keys for the
other IBE CA.
If you make it PFS, then that changes to the recipient's IBE CA can
get
The anonymous IRC project (IIP -- http://www.invisiblenet.net/iip/)
provides encrypted anonymous IRC chat.
Haven't looked in the protocol in detail to see how they get their
anonymity, but the guy seemed aware of Chaum etc and they have crypto
protocols document up there.
They have resource
[copied to cpunks as cryptography seems to have a multi-week lag these
days].
OK, now having read:
http://isrl.cs.byu.edu/HiddenCredentials.html
http://isrl.cs.byu.edu/pubs/wpes03.pdf
and seeing that it is a completely different proposal essentially
being an application of IBE, and extension
The anonymous IRC project (IIP -- http://www.invisiblenet.net/iip/)
provides encrypted anonymous IRC chat.
Haven't looked in the protocol in detail to see how they get their
anonymity, but the guy seemed aware of Chaum etc and they have crypto
protocols document up there.
They have resource
[copied to cpunks as cryptography seems to have a multi-week lag these
days].
OK, now having read:
http://isrl.cs.byu.edu/HiddenCredentials.html
http://isrl.cs.byu.edu/pubs/wpes03.pdf
and seeing that it is a completely different proposal essentially
being an application of IBE, and extension
On Thu, Oct 30, 2003 at 09:06:10AM -0800, James A. Donald wrote:
On 28 Oct 2003 at 13:49, Adam Back wrote:
So for that reason I think Chaum's scheme practically would
not be viable over EC. (Or you could do it but you'd be
better off performance, security and key/messag size doing
Chaum
Fair enough. But this is not Chaum's scheme, it is Wagners and it is
DH based (or ECDH based in your writeup).
You said earlier:
Simple Chaumian blinding works fine on EC.
and the above scheme is not Chaumian blinding. Chaum never invented
DH blinding, if you read Brands thesis even you'll
There are two variants of Brands schemes: over RSA or DH. The DH
variant can be used with the EC. People don't do RSA over EC because
the security argument doesn't work (ie I believe you can do it
technically, but the performance / key size / security arguments no
longer work).
So for that
There are two variants of Brands schemes: over RSA or DH. The DH
variant can be used with the EC. People don't do RSA over EC because
the security argument doesn't work (ie I believe you can do it
technically, but the performance / key size / security arguments no
longer work).
So for that
remops and cpunks:
http://www.1and1.com are offering:
512 MB disk space
ssh and ftp access
pop, mail etc.
5GB/month free bandwidth
cgi/php/mysql
free for 3 years as an advertising ploy to get into small business /
personal web posting.
They use a
remops and cpunks:
http://www.1and1.com are offering:
512 MB disk space
ssh and ftp access
pop, mail etc.
5GB/month free bandwidth
cgi/php/mysql
free for 3 years as an advertising ploy to get into small business /
personal web posting.
They use a
On Thu, Jul 31, 2003 at 12:04:13PM -0400, Trei, Peter wrote:
[...]
with a good distribution of IVs
Where would you store them? The feature of this is that it's fully
transparent, so you can't store IVs anywhere.
I'm not really up on crypto file systems, but I beleive at least some
Look at this shit on fox news, look how they bias the question and
mis-represent the issue.
They ask Should children be allowed to say the Pledge of Allegiance
in school?. As if the children wanted to, and were being prevented!
http://q13.trb.com
and the stats after voting no -- 88% yes.
Adam
Look at this shit on fox news, look how they bias the question and
mis-represent the issue.
They ask Should children be allowed to say the Pledge of Allegiance
in school?. As if the children wanted to, and were being prevented!
http://q13.trb.com
and the stats after voting no -- 88% yes.
Adam
Bill Frantz wrote:
And, I still am willing to work on my brake systems. Replacing pads
on a disk brake unit is a lot easier than replacing drums.
Agree it's easier, and there is very little to get wrong changing disk
brakes -- remove a couple of bolts, using some leverage push the
pistons
Google is likely an eavesdropping hot-spot in intelligence gathering.
A big fraction of web requests go via google. When you're looking for
something particular it's a likely starting point to find a site
specialising in info you need.
Google offers no SSL interface. And anyway from these
Peter lists applied crypto problem in his Crypto Gardening Guide at:
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt
One of the problems from the Problems that Need Solving section is:
* A key wrap function where the wrapping key is derived from a
password. The requirements for
I wrote:
If I recall some time ago (years ago) there was some discussion on
list of using non-US drivers licenses or out-of-state drivers licenses
I think to get around this problem. I thought it was Duncan Frissell
or Black Unicorn who offered some opinions on this.
Below looks like the
If I recall some time ago (years ago) there was some discussion on
list of using non-US drivers licenses or out-of-state drivers licenses
I think to get around this problem. I thought it was Duncan Frissell
or Black Unicorn who offered some opinions on this.
(Actually I am interested in this
If I recall some time ago (years ago) there was some discussion on
list of using non-US drivers licenses or out-of-state drivers licenses
I think to get around this problem. I thought it was Duncan Frissell
or Black Unicorn who offered some opinions on this.
(Actually I am interested in this
And this I guess was the cypherpunks post I was thinking about from
Duncan below.
The only worries then would be if the insurance company would consider
you insured in event of an accident with a non-US license. (Where
that could a Canadian insurance company, or a US insurance company if
you can
On Mon, Nov 04, 2002 at 12:58:55PM -0500, Trei, Peter wrote:
Durden's question was whether a snooper on an IPSEC VPN can
tell (for example) an encrypted email packet from an encrypted
HTTP request.
The answer is no.
All Eve can tell is the FW1 sent FW2 a packet of a certain size.
The
On Mon, Nov 04, 2002 at 12:58:55PM -0500, Trei, Peter wrote:
Durden's question was whether a snooper on an IPSEC VPN can
tell (for example) an encrypted email packet from an encrypted
HTTP request.
The answer is no.
All Eve can tell is the FW1 sent FW2 a packet of a certain size.
The
Some comments on this paper comparing efficiency, and functionality
with Camenisch, Chaum, Brands.
On Tue, Oct 29, 2002 at 11:49:21PM +, Jason Holt wrote:
http://eprint.iacr.org/2002/151/
It mentions how to use the blinding technique Ben Laurie describes
in his Lucre paper, which I don't
Some comments on this paper comparing efficiency, and functionality
with Camenisch, Chaum, Brands.
On Tue, Oct 29, 2002 at 11:49:21PM +, Jason Holt wrote:
http://eprint.iacr.org/2002/151/
It mentions how to use the blinding technique Ben Laurie describes
in his Lucre paper, which I don't
Re. the recent rapacious broadcast royalties imposed on internet
radio in the US, it occurs to me it wouldn't be that hard to do the
following and it would probably avoid the royalties even under the
current imbalanced IP laws:
- have the station broadcast it's own content (commentary)
- have the
Re. the recent rapacious broadcast royalties imposed on internet
radio in the US, it occurs to me it wouldn't be that hard to do the
following and it would probably avoid the royalties even under the
current imbalanced IP laws:
- have the station broadcast it's own content (commentary)
- have the
in the
same way that the TOR and SCP functions can be configured by the user
(but not by hostile software).
For example why not a local user present function to lie about TOR
hash to allow debugging (for example).
Adam Back wrote:
- isn't it quite weak as someone could send different information
Remote attestation does indeed require Palladium to be secure against
the local user.
However my point is while they seem to have done a good job of
providing software security for the remote attestation function, it
seems at this point that hardware security is laughable.
So they disclaim in
in the
same way that the TOR and SCP functions can be configured by the user
(but not by hostile software).
For example why not a local user present function to lie about TOR
hash to allow debugging (for example).
Adam Back wrote:
- isn't it quite weak as someone could send different information
Would someone at MIT / in Boston area like to go to this and send a
report to the list? Might help clear up some of the currently
unexplained aspects about Palladium, such as:
- why they think it couldn't be used to protect software copyright (as
the subject of Lucky's patent)
- are there plans
Would someone at MIT / in Boston area like to go to this and send a
report to the list? Might help clear up some of the currently
unexplained aspects about Palladium, such as:
- why they think it couldn't be used to protect software copyright (as
the subject of Lucky's patent)
- are there plans
Sounds about right. 64 bit crypto in the strong version (which is
not that strong -- the distributed.net challenge recently broke a 64
bit key), and in the export version 24 of those 64 bits were encrypted
with an NSA backdoor key, leaving only 40 bits of key space for the
NSA to bruteforce to
Sounds about right. 64 bit crypto in the strong version (which is
not that strong -- the distributed.net challenge recently broke a 64
bit key), and in the export version 24 of those 64 bits were encrypted
with an NSA backdoor key, leaving only 40 bits of key space for the
NSA to bruteforce to
On Mon, Sep 16, 2002 at 11:01:06PM -0400, Perry E. Metzger wrote:
[...] in a correctly operating OS, MMUs+file permissions do more or
less stop processes from seeing each others data if the OS functions
correctly.
The OS can stop user processes inspecting each others address space.
Therefor a
On Mon, Sep 16, 2002 at 11:01:06PM -0400, Perry E. Metzger wrote:
[...] in a correctly operating OS, MMUs+file permissions do more or
less stop processes from seeing each others data if the OS functions
correctly.
The OS can stop user processes inspecting each others address space.
Therefor a
I put together a list of openpgp related software at:
http://www.cypherspace.org/openpgp/
this includes library only code, and add on software.
Not sure about your questions about key versions, but I forwarded it
to Ulf Moeller and Len Sassaman (current maintainer of mix3).
From what
I put together a list of openpgp related software at:
http://www.cypherspace.org/openpgp/
this includes library only code, and add on software.
Not sure about your questions about key versions, but I forwarded it
to Ulf Moeller and Len Sassaman (current maintainer of mix3).
From what
On Sun, Aug 18, 2002 at 04:58:56PM +0100, Adam Back wrote:
[...] Also relevant is An Efficient System for Non-transferable
Anonymous Credentials with Optional Anonymity Revocation, Jan
Camenisch and Anna Lysyanskaya, Eurocrypt 01
http://eprint.iacr.org/2001/019/
These credentials
With Brands digital credentials (or Chaums credentials) another
approach is to make the endorsement key pair and certificate the
anonymous credential. That way you can use the endorsement key and
certificate directly rather than having to obtain (blinded) identity
certificates from a privacy CA
[resend via different node: [EMAIL PROTECTED] seems to be dead --
primary MX refusing connections]
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
Summary: I think the endorsement key and it's hardware manufacturers
certificate is generated at
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not
On the employment situation... it seems that a lot of applied
cryptographers are currently unemployed (Tim Dierks, Joseph, a few
ex-colleagues, and friends who asked if I had any leads, the spate of
recent security consultant .sigs, plus I heard that a straw poll of
attenders at the codecon
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
Summary: I think the endorsement key and it's hardware manufacturers
certificate is generated at
[resend via different node: [EMAIL PROTECTED] seems to be dead --
primary MX refusing connections]
Phew... the document is certainly tortuous, and has a large number of
similarly and confusingly named credentials, certificates and keys,
however from what I can tell this is what is going on:
I think a number of the apparent conflicts go away if you carefully
track endorsement key pair vs endorsement certificate (signature on
endorsement key by hw manufacturer). For example where it is said
that the endorsement _certificate_ could be inserted after ownership
has been established (not
On the employment situation... it seems that a lot of applied
cryptographers are currently unemployed (Tim Dierks, Joseph, a few
ex-colleagues, and friends who asked if I had any leads, the spate of
recent security consultant .sigs, plus I heard that a straw poll of
attenders at the codecon
It seems from this article that perhaps MS already had worked out how
to do copy protection with Palladium, or at least thinks it possible
contrary to what was said at USENIX security:
http://www.theregister.co.uk/content/4/26651.html
[Palladium related job advert...] Our technology allows
The remote attesation is the feature which is in the interests of
third parties.
I think if this feature were removed the worst of the issues the
complaints are around would go away because the remaining features
would be under the control of the user, and there would be no way for
third parties
On Mon, Aug 12, 2002 at 01:52:39PM +0100, Ben Laurie wrote:
AARG!Anonymous wrote:
[...]
What Palladium can do, though, is arrange that the app can't get at
previously sealed data if the OS has meddled with it. The sealing
is done by hardware based on the app's hash. So if the OS has
feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
On Mon, Aug 12, 2002 at 10:55:19AM -0700, AARG!Anonymous wrote:
Adam Back writes:
+---++
| trusted-agent | user mode |
|space | app space |
|(code
PM 8/12/2002 +0100, Adam Back wrote:
(Tim Dierks: read the earlier posts about ring -1 to find the answer
to your question about feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
The addition of an additional security ring with a secured, protected
On Mon, Aug 12, 2002 at 01:52:39PM +0100, Ben Laurie wrote:
AARG!Anonymous wrote:
[...]
What Palladium can do, though, is arrange that the app can't get at
previously sealed data if the OS has meddled with it. The sealing
is done by hardware based on the app's hash. So if the OS has
feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
On Mon, Aug 12, 2002 at 10:55:19AM -0700, AARG!Anonymous wrote:
Adam Back writes:
+---++
| trusted-agent | user mode |
|space | app space |
|(code
PM 8/12/2002 +0100, Adam Back wrote:
(Tim Dierks: read the earlier posts about ring -1 to find the answer
to your question about feasibility in the case of Palladium; in the
case of TCPA your conclusions are right I think).
The addition of an additional security ring with a secured, protected
we'll see how that works out.
Adam
--
http://www.cypherspace.org/adam/
On Mon, Aug 12, 2002 at 04:32:05PM -0400, Tim Dierks wrote:
At 09:07 PM 8/12/2002 +0100, Adam Back wrote:
At some level there has to be a trade-off between what you put in
trusted agent space and what becomes application code
On Fri, Aug 09, 2002 at 08:25:40PM -0700, AARG!Anonymous wrote:
Several people have objected to my point about the anti-TCPA efforts of
Lucky and others causing harm to P2P applications like Gnutella.
The point that a number of people made is that what is said in the
article is not workable:
Very nice.
Nice plausible set of candidate authors also:
pub 1022/5AC7B865 1992/12/01 [EMAIL PROTECTED]
pub 1024/2B48F6F5 1996/04/10 Ian Goldberg [EMAIL PROTECTED]
pub 1024/97558A1D 1994/01/10 Pr0duct Cypher alt.security.pgp
pub 1024/2719AF35 1995/05/13 Ben Laurie [EMAIL PROTECTED]
On Thu, Aug 08, 2002 at 09:15:33PM -0700, Seth David Schoen wrote:
Back in the Clipper days [...] how do we know that this
tamper-resistant chip produced by Mykotronix even implements the
Clipper spec correctly?.
The picture is related but has some extra wrinkles with the
TCPA/Palladium
On Fri, Aug 09, 2002 at 08:25:40PM -0700, AARG!Anonymous wrote:
Several people have objected to my point about the anti-TCPA efforts of
Lucky and others causing harm to P2P applications like Gnutella.
The point that a number of people made is that what is said in the
article is not workable:
Very nice.
Nice plausible set of candidate authors also:
pub 1022/5AC7B865 1992/12/01 [EMAIL PROTECTED]
pub 1024/2B48F6F5 1996/04/10 Ian Goldberg [EMAIL PROTECTED]
pub 1024/97558A1D 1994/01/10 Pr0duct Cypher alt.security.pgp
pub 1024/2719AF35 1995/05/13 Ben Laurie [EMAIL PROTECTED]
On Thu, Aug 08, 2002 at 09:15:33PM -0700, Seth David Schoen wrote:
Back in the Clipper days [...] how do we know that this
tamper-resistant chip produced by Mykotronix even implements the
Clipper spec correctly?.
The picture is related but has some extra wrinkles with the
TCPA/Palladium
Just read this paper published in PET02 Towards an Information
Theoretic Metric for Anonymity [1]:
http://www.cl.cam.ac.uk/~gd216/set.pdf
or http://www.cl.cam.ac.uk/~gd216/set.ps
it uses a Shannon like entropy model for the anonymity provided by a
system uses this model to analyse
Just read this paper published in PET02 Towards an Information
Theoretic Metric for Anonymity [1]:
http://www.cl.cam.ac.uk/~gd216/set.pdf
or http://www.cl.cam.ac.uk/~gd216/set.ps
it uses a Shannon like entropy model for the anonymity provided by a
system uses this model to analyse
1 - 100 of 174 matches
Mail list logo
