Re: nettime Pirate Utopia, FEED, February 20, 2001

2001-09-20 Thread Adam Back
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),

Re: nettime Pirate Utopia, FEED, February 20, 2001

2001-09-21 Thread Adam Back
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

Re: nettime Pirate Utopia, FEED, February 20, 2001

2001-09-22 Thread Adam Back
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

Re: limits of watermarking (Re: First Steganographic Image in theWild)

2001-10-19 Thread Adam Back
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

limits of watermarking (Re: First Steganographic Image in the Wild)

2001-10-16 Thread Adam Back
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

Re: limits of watermarking (Re: First Steganographic Image in the Wild)

2001-10-17 Thread Adam Back
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

Re: PGP GPG compatibility

2002-01-21 Thread Adam Back
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

Re: Secure peripheral cards

2002-03-21 Thread Adam Back
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

fast SSL accelerators (Re: Secure peripheral cards)

2002-03-23 Thread Adam Back
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

Re: RSA on general-purpose CPU's [was:RE: Secure peripheral cards]

2002-03-25 Thread Adam Back
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

ciphersaber-2 human memorable test vectors

2002-03-28 Thread Adam Back
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

Re: ciphersaber-2 human memorable test vectors

2002-03-30 Thread Adam Back
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

what is GPG's #1 objective: security or anti-patent stance ( Re: on the state of PGP compatibility (2nd try))

2002-04-01 Thread Adam Back
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

objectivity and factoring analysis

2002-04-20 Thread Adam Back
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

Re: objectivity and factoring analysis

2002-04-22 Thread Adam Back
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

Re: Shortcut digital signature verification failure

2002-06-21 Thread Adam Back
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

Re: Ross's TCPA paper

2002-06-26 Thread Adam Back
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

DRMs vs internet privacy (Re: Ross's TCPA paper)

2002-06-26 Thread Adam Back
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

p2p DoS resistance and network stability (Re: Thanks, Lucky, for helping to kill gnutella)

2002-08-10 Thread Adam Back
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:

trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-12 Thread Adam Back
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

Re: trade-offs of secure programming with Palladium (Re: Palladium: technical limits and implications)

2002-08-12 Thread Adam Back
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

TCPA/Palladium user interst vs third party interest (Re: responding to claims about TCPA)

2002-08-14 Thread Adam Back
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

TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)

2002-08-15 Thread Adam Back
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

Re: TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA)

2002-08-15 Thread Adam Back
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

employment market for applied cryptographers?

2002-08-16 Thread Adam Back
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

Re: Cryptographic privacy protection in TCPA

2002-08-18 Thread Adam Back
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

Re: comparing RMAC to AES+CBC-MAC or XCBC (Re: Why is RMAC resistant to birthday attacks?)

2002-10-23 Thread Adam Back
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

Re: palladium presentation - anyone going?

2002-10-21 Thread Adam Back
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

Re: Why is RMAC resistant to birthday attacks?

2002-10-21 Thread Adam Back
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

comparing RMAC to AES+CBC-MAC or XCBC (Re: Why is RMAC resistant to birthday attacks?)

2002-10-22 Thread Adam Back
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

Re: comparing RMAC to AES+CBC-MAC or XCBC (Re: Why is RMAC resistant to birthday attacks?)

2002-10-24 Thread Adam Back
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

palladium presentation - anyone going?

2002-10-17 Thread Adam Back
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

Palladium -- trivially weak in hw but secure in software?? (Re: palladium presentation - anyone going?)

2002-10-22 Thread Adam Back
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

Re: patent free(?) anonymous credential system pre-print

2002-10-30 Thread Adam Back
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

deadbeef attack was choose low order RSA bits (Re: Key Pair Agreement?)

2003-01-21 Thread Adam Back
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

Re: deadbeef attack was choose low order RSA bits (Re: Key Pair Agreement?)

2003-01-23 Thread Adam Back
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

password based key-wrap (Re: The Crypto Gardening Guide and Planting Tips)

2003-02-07 Thread Adam Back
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

Re: NSA being used to influence UN votes on Iraq

2003-03-05 Thread Adam Back
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