Why is US secret service eavesdropping and dirty tricks against UN
votes on Iraq news worthy?
Because it's an attempt to pervert the political process, and sabotage
the political representation of other UN member countries.
I'm sure it is a little more than delegations bothering to protect
their
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
No that's not the way it would work.
There would be a secure remote attestation certified by the
endoresment key which is signed by the hw manufacturer and never
leaves the device. Bound to this attestation would be a key exchange
which results the device negotiating a shared key with the music
s
On Wed, Jan 22, 2003 at 03:18:34PM +1300, Peter Gutmann wrote:
> >One cheap way the low order 64 bits can be set is to set the low order bits
> >of p to the target bitset and the low order bits of q to ...1 (63 0s and
> >one 1 in binary), and then to increase the stride of candidate values in t
On Mon, Jan 20, 2003 at 09:08:31PM -0500, Radia Perlman wrote:
> [...] I was going to suggest something similar to what David Wagner
> suggested, but with Scott telling Alice the modulus size and the
> *high* order 64 bits (with the top bit constrained to be 1). I can
> see how Alice can easily gen
I hear that as new-zealand made it illegal to sell region restricted
DVD players there (as John mentioned in his mail), that units (any
brand) bought for the .nz market are all region players. Shouldn't be
hard to get one mail order of your choice. (Or so a .nz person told
me -- he's on the list)
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 do
On Thu, Oct 24, 2002 at 02:08:11AM -0700, Sidney Markowitz wrote:
> [...] XCBC should be inherently resistant to extension forgery
> attacks. The attack requires that the MAC have the property that
> MAC(x) == MAC(y) implies that MAC(x||z) == MAC(y||z). In the case of
> XCBC, because of the padding
The problem with this one-size fits all approach is that for most
applications given the key size of AES, the extension forgery is
impractical. It would be more flexible to specify RMAC as having an
optional salt, with the size determined by the implementer as
appropriate for their scenario.
So m
But the salt doesn't increase the MAC length. It just frustrates
attempts to collect message+MAC pairs to find a collision. Think of
it like a salt on unix passwords. You can still brute force one
particular target in the same time, but the salt reduces your scope
for pre-computation.
There is
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 t
I think they are presuming there will be no encryption, so Eve can
verify collisions by observing the MAC values. Eve just records
messages and their MACs that Alice sends Bob. They are also presuming
exceedingly long lived MAC keys. (If you changed keys the collection
of messages would have to
user present test 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 w
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
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
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
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 a
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 conf
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
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 manufac
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
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 con
d Agent APIs flexible,
so 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
> >tru
> At 07:30 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 ad
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 spac
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 O
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:
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 a
John Allen's md5-in-perl?
http://www.cypherspace.org/adam/rsa/md5.html
#!/usr/bin/perl -iH9T4C`>_-JXF8NMS^$#)4=@<,$18%"0X4!`L0%P8*#Q4``04``04#!P``
@A=unpack N4C24,unpack u,$^I;@K=map{int abs 2**32*sin$_}1..64;sub L{($x=pop)
<<($n=pop)|2**$n-1&$x>>32-$n}sub M{($x=pop)-($m=1+~0)*int$x/$m}do{$l+=$r
On Wed, Jun 26, 2002 at 03:57:15PM -0400, C Wegrzyn wrote:
> If a DRM system is based on X.509, according to Brand I thought you could
> get anonymity in the transaction. Wouldn't this accomplish the same thing?
I don't mean that you would necessarily have to correlate your viewing
habits with yo
On Wed, Jun 26, 2002 at 10:01:00AM -0700, bear wrote:
> As I see it, we can get either privacy or DRM,
> but there is no way on Earth to get both.
> [...]
Hear, hear! First post on this long thread that got it right.
Not sure what the rest of the usually clueful posters were thinking!
DRM syst
un 21, 2002 at 11:42:22AM -0400, Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, Adam Back writes:
> >Doesn't a standard digital signature plus hashcash / client puzzles
> >achieve this effect?
>
> That involves extra round trips, and a
Doesn't a standard digital signature plus hashcash / client puzzles
achieve this effect?
The hashcash could be used to make the client to consume more cpu than
the server. The hashcash collision wouldn't particularly have to be
related to the signature, as the collision would just act as a
proof
Nicko writes:
> [...] the Bernstein proposal [...] (among other things) it details
> the conceptual design of a machine for computing kernels in a large,
> sparse matrix. The design talks of the number of functional units
> and the nature of the communication between these units. What I set
> ou
I'd just like to make a few comments about the apparently unnoticed or
unstated conflicts of interest and bias in the analysis surrounding
Bernstein's proposal.
The following is not intended to trample on anyone's ego -- but I
think deserves saying.
- I'm not sure any of the respondents so far e
Hi
I've trimmed the Cc line a bit as this is now focussing more on GPG
and not adding any thing new technically for the excluded set.
On Sun, Mar 31, 2002 at 06:08:14PM -0500, David Shaw wrote:
> The OpenPGP spec handles compatibility issues quite well.
> The catch, of course, is that PGP 2.x
[This is actually slightly more accurate and even worse than my first
mail which bounced to some of the lists as I had a typo, _and_
separately encountered a mail hub outage at cyberpass.net -- apologies
to those who get duplicates].
So I was trying to decrypt this stored mail sent to me by a GPG
On Sat, Mar 30, 2002 at 08:27:02AM -0800, Jeff Cours wrote:
> On Fri, 29 Mar 2002, Adam Back wrote:
>
> > Any takers on ciphersaber-2 test vectors which are also topical
> > and amusing english phrases?
>
> Is there a faster way to search the test vector space than bru
On Fri, Mar 29, 2002 at 01:49:30PM -0800, Bill Frantz wrote:
> At 10:15 AM -0800 3/26/02, Adam Back wrote:
> >In general purely human readable test vectors are not ideal as they
> >are 7 bit, and there have been cases where implementation errors or
> >related to the 7th
A while ago I wrote some code to search for human readable test
vectors for Arnold Reinhold's ciphersaber-2
(http://ciphersaber.gurus.com).
Ciphersaber-2 is designed to be simple enough to be implemented from
memory, to avoid the risk of being caught with crypto software on your
computer for use
On Sat, Mar 23, 2002 at 05:00:12PM -0800, Eric Young wrote:
> >>openSSL on a PIII-633Mhz can do 265 512 bit CRT RSA per
>
> I don't know what the OpenSSL people did to the x86 ASM code, but
> SSLeay (the precursor to OpenSSL, over 3 years old) did/does 330
> 512bit and 55 1024 bit RSAs a second
On Fri, Mar 22, 2002 at 03:39:01PM +1100, Greg Rose wrote:
> But don't forget that your pentium can't do anything *else* while it's
> doing those RSAs... whereas the machine with the nForce can be actually
> servicing the requests.
While that is true, the issue is the economics; depending on th
On Thu, Mar 21, 2002 at 10:02:20AM -0500, R. A. Hettinga wrote:
> At 7:21 PM -0500 on 3/20/02, Roop Mukherjee wrote:
> > I am searching for some citable references about secure peripheral cards.
> > Contrary to what I had imagined when I had started searching, I found very
> > little. I am looking
It's quite hard to guarantee that no one has unattended access to your
machine at any time.
A paranoid user could checksum his binaries, and keep the checksum and
minimal boot image on a flash USB fob, or boot off a CDROM, and keep
the checksum on flash. Then the user could again consider the
If you ask me GPG has as much to answer for in the
non-interoperability problems with it's rejection of shipping IDEA
with the default GPG as PRZ et al for deciding to not ship RSA.
I tried arguing with PGP that if they wanted to phase out RSA use, the
best way would be to support it: then more p
On Fri, Oct 19, 2001 at 10:24:55AM -0400, Roop Mukherjee wrote:
> The analogy was intended towards publicy know provably strong means
> of copy protection.
But no such schemes exist, and as I was arguing earlier, I don't think
they will be found either because there are fundamental problems with
t aware and connected users, increasing scale of file-sharing
networks; whereas devices needing hardware modifications have non-zero
reproduction costs, and risk of damaging expensive equipment in the
operation.
On Wed, Oct 17, 2001 at 10:23:03AM +0100, Ben Laurie wrote:
> Adam Back wrote:
&g
On Tue, Oct 16, 2001 at 11:30:05AM -0700, Greg Broiles wrote:
> Adam Back wrote:
> >Stego isn't a horseman, and the press drumming up scare stories around
> >stego is ludicrous. We don't need any more stupid cryptography or
> >internet related laws. More stupid
If you read the web page it was just a demo created by ABC news --
that doesn't count as found in the wild. Not that it would be that
far out to find the odd image in the wild created as a novelty by
someone tinkering with stego software, or perhaps even individuals
playing with stego.
Stego isn
On Fri, Sep 21, 2001 at 06:19:43PM +0100, Adam Back wrote:
> My point was higher level. These systems are either already broken or
> fragile and very lightly peer reviewed. There aren't many people
> building and breaking them.
To elaborate on this slightly. There are inhere
My point was higher level. These systems are either already broken or
fragile and very lightly peer reviewed. There aren't many people
building and breaking them.
I did read the papers; my summary is the above, and from that I
surmise it would not be wise for a terrorist to use current generati
Also it's interesting to note that it appears from Niels Provos and
Peter Honeymans paper that none of the currently available stego
encoding programs are secure. They have broken them all (at least I
recognise the main stego programs available in their list of systems
their tools can attack), an
ID based PKC systems have another application which is very useful:
non-interactive forward secrecy. Ross Anderson has a nice write up of the
equivalence here:
http://www.cl.cam.ac.uk/ftp/users/rja14/forwardsecure.pdf
particulary section 1.3. An ID based PKC system can be used to build
53 matches
Mail list logo
