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 for
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 the
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
out to
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
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
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 brute
force? Only certain output
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 a
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 the
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 to
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
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
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:
[...why copymarks don't work...]
[...]
It seems
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 laws will not make anyone safer.
I
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 inherent reasons why
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
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),
38 matches
Mail list logo