Re: Session Fixation Vulnerability in Web Based Apps

2003-06-14 Thread Ben Laurie
James A. Donald wrote: -- On 12 Jun 2003 at 16:25, Steve Schear wrote: http://www.acros.si/papers/session_fixation.pdf Wow. This flaw is massive, and the biggest villain is the server side code created for Apache. When you login to your bank, your e-gold account, your

Re: Announcing httpsy://, a YURL scheme

2003-07-15 Thread Ben Laurie
Ed Gerck wrote: From your URLs: The browser verifies that the fingerprint in the URL matches the public key provided by the visited site. Certificates and Certificate Authorities are unnecessary. Spoofing? Man-in-the-middle? Revocation? Also, in general, we find that one reference

Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification

2003-09-06 Thread Ben Laurie
Joshua Hill wrote: On Fri, Sep 05, 2003 at 06:02:10PM -0400, Wei Dai wrote: In fact they wouldn't even validate Crypto++ as a static library despite an earlier verbal agreement that a static library was ok. It had to be turned into a DLL at the last moment (i.e. during the review phase).

Re: OpenSSL *source* to get FIPS 140-2 Level 1 certification

2003-09-06 Thread Ben Laurie
Wei Dai wrote: On Fri, Sep 05, 2003 at 04:15:22PM -0400, Anton Stiglic wrote: You are correct, I just saw Crypto++ in the list of FIPS 140 validated modules: http://csrc.nist.gov/cryptval/140-1/140val-all.htm It is the latest entry, added today. Congratulations to Wei Dai! Thanks! Also

Re: Is cryptography where security took the wrong branch?

2003-09-07 Thread Ben Laurie
Eric Rescorla wrote: Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good enough. I don't think so. One of the things I'm running into

Re: Is cryptography where security took the wrong branch?

2003-09-08 Thread Ben Laurie
Eric Rescorla wrote: Ben Laurie [EMAIL PROTECTED] writes: Eric Rescorla wrote: Incidentally, when designing SHTTP we envisioned that credit transactions would be done with signatures. I would say that the Netscape guys were right in believing that confidentiality for the CC number was good

Re: Monoculture

2003-10-04 Thread Ben Laurie
Thor Lancelot Simon wrote: As far as what OpenSSL does, if you simply abandon outright any hope of acting as a certificate authority, etc. you can punt a huge amount of complexity; if you punt SSL, you'll lose quite a bit more. As far as the programming interface goes, I'd read Eric's book

Re: Monoculture

2003-10-04 Thread Ben Laurie
[EMAIL PROTECTED] wrote: On Thu, 2 Oct 2003, Thor Lancelot Simon wrote: 1) Creates a socket-like connection object 2) Allows configuration of the expected identity of the party at the other end, and, optionally, parameters like acceptable cipher suite 3) Connects, returning error if the

Re: Other OpenSSL-based crypto modules FIPS 140 validated?

2003-10-07 Thread Ben Laurie
Peter Gutmann wrote: Nathan P. Bardsley [EMAIL PROTECTED] writes: Anecdotally, I've heard that there are many, but almost all of them were done by vendors for embedding in their proprietary products. Ditto. The problem is that when vendors have spent $100K+ on the certification,

Re: [e-lang] Re: Protocol implementation errors

2003-10-08 Thread Ben Laurie
Peter Gutmann wrote: Ben Laurie [EMAIL PROTECTED] writes: Peter Gutmann wrote: ASN.1 has a *reputation* of being notoriously hard to parse, gained chiefly from some early bad experiences with OSI work (which would give anything a reputation of being hard to work with :-). I've implemented

Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-09 Thread Ben Laurie
Jill Ramonsky wrote: Too late. I've already started. Besides which, posts on this group suggest that there is a demand for such a toolkit. I think there's demand in the sense that there's demand for free lunches. People would like the inherent complexity to go away, because they can see that

Re: Monoculture

2003-10-11 Thread Ben Laurie
Thor Lancelot Simon wrote: On Sun, Oct 05, 2003 at 03:04:00PM +0100, Ben Laurie wrote: Thor Lancelot Simon wrote: On Sat, Oct 04, 2003 at 02:09:10PM +0100, Ben Laurie wrote: Thor Lancelot Simon wrote: these operations. For example, there is no simple way to do the most common

Re: Open Source (was Simple SSL/TLS - Some Questions)

2003-10-11 Thread Ben Laurie
Peter Clay wrote: On Thu, 9 Oct 2003, Peter Gutmann wrote: I would add to this the observation that rather than writing yet another SSL library to join the eight hundred or so already out there, it might be more useful to create a user-friendly management interface to IPsec implementations

VPN List Announcement

2003-10-11 Thread Ben Laurie
Since I'm sure Perry will eventually get tired of VPNs, before he does I should announce that I have, at the request of several participants in the recent discussions, set up a list for VPN theory discussion. It is currently unmoderated, though I reserve the option to change that if warranted.

Re: Super-Encryption

2003-12-15 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Sender's Algorithm SymmetricKey1 = 3DES_IV1, 3DES_Key1 Cipher1 = 3DES_Encrypt(message) Digest = SHA1(message) RSA_Key1 = RSA_Private_Encrypt(Digest || 3DES_Key1) SymmetricKey2 = 3DES_IV2, 3DES_Key2 Cipher2 = 3DES_Encrypt(Cipher1) RSA_Key2 = RSA_Public_Encrypt(3DES_Key2)

Re: Super-Encryption

2003-12-18 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Quoting Ben Laurie [EMAIL PROTECTED]: I don't see any value added by cipher1 - what's the point? The message is encrypted, i.e, cipher1, then cipher1 is encrypted yeilding cipher2. Since symmetric_key1 of cipher1 is RSA_Encrypt(sender's private key), access

Re: Super-Encryption

2003-12-18 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Quoting Ben Laurie [EMAIL PROTECTED]: Yes, but you could know all this from cipher2 and RSA of SHA1(message), so I still don't see what value is added by cipher1. Without cipher1, implying (iv1, RSA(SHA1(message) || key1)) it is impossible to determine

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

2003-12-20 Thread Ben Laurie
Carl Ellison wrote: It is an advantage for a TCPA-equipped platform, IMHO. Smart cards cost money. Therefore, I am likely to have at most 1. If I glance quickly through my wallet, I find 7 smartcards (all credit cards). Plus the one in my phone makes 8. So, run that at most 1 argument past me

Re: Difference between TCPA-Hardware and a smart card (was: example: secure computing kernel needed)

2003-12-22 Thread Ben Laurie
Carl Ellison wrote: We see here a difference between your and my sides of the Atlantic. Here in the US, almost no one has a smart card. Of those cards you carry, how many are capable of doing public key operations? A simple memory smartcard doesn't count for what we were talking about. I don't

Re: I don't know PAIN...

2003-12-22 Thread Ben Laurie
Ian Grigg wrote: What is the source of the acronym PAIN? Lynn said: ... A security taxonomy, PAIN: * privacy (aka thinks like encryption) * authentication (origin) * integrity (contents) * non-repudiation I.e., its provenance? Google shows only a few hits, indicating it is not widespread.

Re: Difference between TCPA-Hardware and other forms of trust

2003-12-22 Thread Ben Laurie
bear wrote: I really don't care if anyone *else* trusts my system; as far as I'm concerned, their secrets should not be on my system in the first place, any more than my secrets should be on theirs. The problem is that their secrets are Snow White, or the latest Oasis album. You want them on your

Re: Difference between TCPA-Hardware and other forms of trust

2003-12-22 Thread Ben Laurie
Bill Frantz wrote: One should note that TCPA is designed to store its data (encrypted) in the standard file system, so standard backup and restore techniques can be used. Only if your box doesn't die. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no

Re: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-28 Thread Ben Laurie
Ian Grigg wrote: Carl and Ben have rubbished non-repudiation without defining what they mean, making it rather difficult to respond. I define it quite carefully in my paper, which I pointed to. Now, presumably, they mean the first, in that it is a rather hard problem to take the cryptographic

Re: Microsoft publicly announces Penny Black PoW postage project

2003-12-28 Thread Ben Laurie
Steve Schear wrote: http://news.bbc.co.uk/2/hi/technology/3324883.stm Adam Back is part of this team, I think. Similar approach to Camram/hahscash. Memory-based approaches have been discussed. Why hasn't Camram explored them? They were only invented recently, and indeed, I've been planning

Re: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-29 Thread Ben Laurie
Amir Herzberg wrote: Ian proposes below two draft-definitions for non-repudiation - legal and technical. Lynn also sent us a bunch of definitions. Let's focus on the technical/crypto one for now - after all this is a crypto forum (I agree the legal one is also somewhat relevant to this forum).

Re: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-29 Thread Ben Laurie
Carl Ellison wrote: If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that s/he accepts liability for any digitally signed

Re: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-29 Thread Ben Laurie
Carl Ellison wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kelm Sent: Tuesday, December 23, 2003 1:44 AM To: [EMAIL PROTECTED] Subject: Re: Non-repudiation (was RE: The PAIN mnemonic) Ah. That's why they're trying to rename the

Re: Non-repudiation (was RE: The PAIN mnemonic)

2003-12-29 Thread Ben Laurie
Amir Herzberg wrote: At 04:20 25/12/2003, Carl Ellison wrote: ... If you want to use cryptography for e-commerce, then IMHO you need a contract signed on paper, enforced by normal contract law, in which one party lists the hash of his public key (or the whole public key) and says that

Re: why penny black etc. are not very useful

2003-12-31 Thread Ben Laurie
Perry E. Metzger wrote: In my opinion, the various hashcash-to-stop-spam style schemes are not very useful, because spammers now routinely use automation to break into vast numbers of home computers and use them to send their spam. They're not paying for CPU time or other resources, so they won't

Re: [camram-spam] Re: Microsoft publicly announces Penny Black PoW postage project

2003-12-31 Thread Ben Laurie
Richard Clayton wrote: and in these schemes, where does our esteemed moderator get _his_ stamps from ? remember that not all bulk email is spam by any means... or do we end up with whitelists all over the place and the focus of attacks moves to the ingress to the mailing lists :( He uses the

Announcement: New mailing list for UK crypto

2004-04-01 Thread Ben Laurie
By popular demand, I've created a moderated alternative to the UKCrypto mailing list. See https://mailman.aldigital.co.uk/mailman/listinfo/ukcisnac for the charter and subscription information. This is intended to be complementary to the cryptography (because its about the UK) and ukcrypto

Re: The future of security

2004-06-02 Thread Ben Laurie
Peter Gutmann wrote: No they won't. All the ones I've seen are some variant on the build a big wall around the Internet and only let the good guys in, which will never work because the Internet doesn't contain any definable inside and outside, only 800 million Manchurian candidates waiting to

Re: 3. Proof-of-work analysis

2004-06-04 Thread Ben Laurie
Adam Back wrote: 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

Re: Is finding security holes a good idea?

2004-06-14 Thread Ben Laurie
Eric Rescorla wrote: Cryptography readers who are also interested in systems security may be interested in reading my paper from the Workshop on Economics and Information Security '04: Is finding security holes a good idea? Eric Rescorla RTFM, Inc. A large amount of effort is

Re: Passwords can sit on disk for years

2004-06-22 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Ben Laurie wrote: In OpenSSL we overwrite with random gunk for this reason. What? No compiler is smart enough to say, The program sets these variables but they are never referenced again. I'll save time and not set them. Sure it is, here's gcc -O3: main() { int

Re: Microsoft .NET PRNG (fwd)

2004-08-22 Thread Ben Laurie
Anton Stiglic wrote: There is some detail in the FIPS 140 security policy of Microsoft's cryptographic provider, for Windows XP and Windows 2000. See for example http://csrc.nist.gov/cryptval/140-1/140sp/140sp238.pdf where they say the RNG is based on FIPS 186 RNG using SHS. The seed is based on

Re: Cryptography and the Open Source Security Debate

2004-08-25 Thread Ben Laurie
lrk wrote: On Thu, Aug 12, 2004 at 03:27:07PM -0700, Jon Callas wrote: On 10 Aug 2004, at 5:16 AM, John Kelsey wrote: So, how many people on this list have actually looked at the PGP key generation code in any depth? Open source makes it possible for people to look for security holes, but it

Re: HMAC?

2004-08-26 Thread Ben Laurie
Amir Herzberg wrote: Perry E. Metzger wrote: So the question now arises, is HMAC using any of the broken hash functions vulnerable? Considering that HMAC goal is `only` a MAC (shared key authentication), the existence of any collision is not very relevant to its use. But furthermore, what HMAC

Re: public-key: the wrong model for email?

2004-09-18 Thread Ben Laurie
Ed Gerck wrote: Anne Lynn Wheeler wrote: the issue then is what level do you trust the recipient, what is the threat model, and what are the countermeasures. if there is a general trust issue with the recipient (not just their key generating capability) ... then a classified document

Re: public-key: the wrong model for email?

2004-09-22 Thread Ben Laurie
Ed Gerck wrote: Ben Laurie wrote: Ed Gerck wrote: If the recipient cannot in good faith detect a key-access ware, or a GAK-ware, or a Trojan, or a bug, why would a complete background check of the recipient help? Let's assume for a moment that a solution exists that satisfies your requirements

Re: Linux-based wireless mesh suite adds crypto engine support

2004-10-06 Thread Ben Laurie
John Gilmore wrote: Crypto hardware that generates random numbers can't be tested in production in many useful ways. My suggestion would be to XOR a hardware-generated and a software-generated random number stream. If one fails, whether by accident, malice, or design, the other will still

Customs and Excise Electronic Returns

2004-09-29 Thread Ben Laurie
Background, for non-Brits: Customs Excise (CE) is the government department responsible for collecting VAT (Value Added Tax), which is a European sales tax. Businesses report their VAT transactions quarterly to CE, currently mostly on paper (a one page form, amazingly) - this is known as a

Re: Printers betray document secrets

2004-10-25 Thread Ben Laurie
Marshall Clow wrote: At 10:44 PM -0700 10/20/04, Bill Stewart wrote: At 05:23 PM 10/18/2004, R.A. Hettinga wrote: http://news.bbc.co.uk/2/low/technology/3753886.stm It's not clear that they work at all with inkjet printers, and changing ink cartridges is even more common than changing laser

Re: [off-topic, but not by ukcrypto standards] ukcrypto-moderated pre-moderators needed

2004-11-01 Thread Ben Laurie
Peter Fairbrother wrote: Ben Laurie wrote: OK, since my previous attempt to create a lower volume ukcrypto-like-thing failed, I have concluded that the only way to handle the problem is to produce a moderated version of ukcrypto. I know for sure there's demand for this, but I also know

Re: Financial identity is *dangerous*? (was re: Fake companies, real money)

2004-11-01 Thread Ben Laurie
Ian Grigg wrote: Alan Barrett wrote: On Sat, 23 Oct 2004, Aaron Whitehouse wrote: Oh, and make it small enough to fit in the pocket, put a display *and* a keypad on it, and tell the user not to lose it. How much difference is there, practically, between this and using a smartcard credit card in

Re: Your source code, for sale

2004-11-06 Thread Ben Laurie
Tyler Durden wrote: Hum. So my newbie-style question is, is there an eGold that can be verified, but not accessed, until a 'release' code is sent? proof-of-delivery protocols might help (but they're patented, as I discovered when I reinvented them a few years back). In other words, say I'm

Re: The Pointlessness of the MD5 attacks

2004-12-14 Thread Ben Laurie
Ondrej Mikle wrote: On Tue, 14 Dec 2004 14:43:24 +, Ben Laurie [EMAIL PROTECTED] wrote: But the only way I can see to exploit this would be to have code that did different things based on the contents of some bitmap. My contention is that if the code is open, then it will be obvious

Re: The Pointlessness of the MD5 attacks

2004-12-15 Thread Ben Laurie
Adam Back wrote: I thought the usual attack posited when one can find a collision on a source checksum is to make the desired change to source, then tinker with something less obvious and more malleable like lsbits of a UI image file until you find your collision on two input source packages.

Re: The Pointlessness of the MD5 attacks

2004-12-15 Thread Ben Laurie
Adam Back wrote: Well the people doing the checking (a subset of the power users) may say I checked the source and it has this checksum, and another user may download that checksum and be subject to MITM and not know it. Or I could mail you the source and you would check it with checksum and

The Pointlessness of the MD5 attacks

2004-12-14 Thread Ben Laurie
Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. But the only way I can see to exploit this would be to have code that did different things

Re: The Pointlessness of the MD5 attacks

2004-12-15 Thread Ben Laurie
Bill Frantz wrote: On 12/14/04, [EMAIL PROTECTED] (Ben Laurie) wrote: Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. But the only way I can

Re: The Pointlessness of the MD5 attacks

2004-12-15 Thread Ben Laurie
and attest to the correctness of code C, and then we can MITM and change surrepticiously with C'. And with only 2^64 effort. Let me know when you're done. Adam On Wed, Dec 15, 2004 at 08:44:03AM +, Ben Laurie wrote: Adam Back wrote: Well the people doing the checking (a subset of the power users

Re: The Pointlessness of the MD5 attacks

2004-12-22 Thread Ben Laurie
John Kelsey wrote: So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code is untrusted anyway, so being able to change its behaviour on the basis of embedded bitmap changes is a parlour trick. You may as well have it ping a website

Re: The Pointlessness of the MD5 attacks

2004-12-22 Thread Ben Laurie
Jay Sulzberger wrote: On Tue, 14 Dec 2004, Ben Laurie wrote: Ondrej Mikle wrote: [snipped many assertions without supporting evidence that MD5 cracks improve attacks] So, to exploit this successfully, you need code that cannot or will not be inspected. My contention is that any such code

Re: The Pointlessness of the MD5 attacks

2004-12-22 Thread Ben Laurie
David Wagner wrote: Ben Laurie writes: Dan Kaminsky's recent posting seems to have caused some excitement, but I really can't see why. In particular, the idea of having two different executables with the same checksum has attracted attention. But the only way I can see to exploit this would

Re: The Pointlessness of the MD5 attacks

2005-01-05 Thread Ben Laurie
C. Scott Ananian wrote: On Wed, 22 Dec 2004, Ben Laurie wrote: Blimey. Finally. An attack I can actually believe in. Excellent

Entropy and PRNGs

2005-01-07 Thread Ben Laurie
Given recent discussion, this is perhaps a good moment to point at a paper I wrote a while back on PRNGs for Dr. Dobbs, where, I'll bet, most of you didn't read it. http://www.apache-ssl.org/randomness.pdf One day, I plan to implement the API I describe there. Cheers, Ben. --

Re: entropy depletion

2005-01-11 Thread Ben Laurie
William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy generator(s). Surely observation of /dev/urandom's

Re: entropy depletion

2005-01-26 Thread Ben Laurie
William Allen Simpson wrote: Ben Laurie wrote: William Allen Simpson wrote: Why then restrict it to non-communications usages? Because we are starting from the postulate that observation of the output could (however remotely) give away information about the underlying state of the entropy

Re: [IP] SHA-1 cracked?

2005-02-17 Thread Ben Laurie
David Farber wrote: -- Forwarded Message From: Rodney Joffe [EMAIL PROTECTED] Date: Wed, 16 Feb 2005 07:36:36 -0700 To: Dave Farber [EMAIL PROTECTED] Subject: SHA-1 cracked? For IP Hi Dave, Bruce Schneier is reporting in his blog that SHA-1 appears to have been broken by a Chinese group, and

Re: A cool demo of how to spoof sites (also shows how TrustBar preventsthis...)

2005-02-22 Thread Ben Laurie
Taral wrote: On Wed, Feb 09, 2005 at 07:41:36PM +0200, Amir Herzberg wrote: Want to protect your Mozilla/FireFox from such attacks? Install our TrustBar: http://TrustBar.Mozdev.org (this was the first time that I had a real reason to click the `I don't trust this authority` button...) Opinions?

MD5 collision in X509 certificates

2005-03-03 Thread Ben Laurie
Cute. I expect we'll see more of this kind of thing. http://eprint.iacr.org/2005/067 Executive summary: calculate chaining values (called IV in the paper) of first part of the CERT, find a colliding block for those chaining values, generate an RSA key that has the collision as the first part of

Re: MD5 collision in X509 certificates

2005-03-03 Thread Ben Laurie
Dan Kaminsky wrote: The x.509 cert collision is a necessary consequence of the earlier discussed prime/not-prime collision. Take the previous concept, make both prime, and surround with the frame of an x.509 cert, and you get the new paper. Actually, not - an RSA public key is not prime.

Re: NSA names ECC as the exclusive technology for key agreement and digital signature standards for the U.S. government

2005-03-20 Thread Ben Laurie
Ian G wrote: NSA names ECC as the exclusive technology for key agreement and digital signature standards for the U.S. government Certicom's ECC-based solutions enable government contractors to add security that meets NSA guidelines I should note that OpenSSL also supports ECC. --

Propping up SHA-1 (or MD5)

2005-03-21 Thread Ben Laurie
It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is

Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Dan Kaminsky wrote: Ben, x can equal either test vector released by Wang, and H(x) will be identical. With H(x) identical, the rest of the HMAC stays identical too. This does not appear to be correct - in my construction, i.e. without padding, then the fact that x and x' differ means that

Re: [saag] Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Nicolas Williams wrote: On Mon, Mar 21, 2005 at 11:56:44AM +, Ben Laurie wrote: It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) Eric

Re: [saag] Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Ken Raeburn wrote: On Mar 22, 2005, at 11:51, Ben Laurie wrote: This can be fixed quite easily: H'(x)=H(H(x || H(x)) || H(x)) Doesn't this take us back to the original problem, by factoring in x only at the start of hash computations, so H'(x') will generate the same H(x') and the same internal

Re: [saag] Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Nicolas Williams wrote: On Tue, Mar 22, 2005 at 05:31:44PM +, Ben Laurie wrote: Nicolas Williams wrote: Now that we know that the attack is a differential cryptanalysis where the attacker has to control the first pair of blocks of the original message anything that makes it hard

Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Charlie Kaufman wrote: All hash functions I'm aware of consist of an inner compression function that hashes a fixed size block of data into a smaller fixed size block and an outer composition function that applies the inner function iteratively to the variable length data to be hashed. Essentially

Re: [saag] Re: Propping up SHA-1 (or MD5)

2005-03-25 Thread Ben Laurie
Blumenthal, Uri wrote: Ernie Brickell suggested the following construct: H'(x) = H( H(x) || H(0 || x) ) Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)). Sorry, I got my parentheses wrong. I meant... H'(x)=H(H(x || H(0 || x)) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x)) ||

Re: Malaysia car thieves steal finger

2005-05-20 Thread Ben Laurie
R.A. Hettinga wrote: Police in Malaysia are hunting for members of a violent gang who chopped off a car owner's finger to get round the vehicle's hi-tech security system. Good to know that my amputationware meme was not just paranoia. -- http://www.apache-ssl.org/ben.html

Re: [Lucrative-L] double spends, identity agnosticism, and Lucrative

2005-05-20 Thread Ben Laurie
James A. Donald wrote: From: Patrick [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Lucrative-L] double spends, identity agnosticism, and Lucrative Date: Tue, 29 Apr 2003 14:46:48 -0600 Importance: Normal Sender: [EMAIL PROTECTED] A quick experiment has confirmed the obvious: when a client

Re: What happened with the session fixation bug?

2005-05-20 Thread Ben Laurie
James A. Donald wrote: -- PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected. However, the session fixation bugs http://www.acros.si/papers/session_fixation.pdf make https and PKI worthless

Re: What happened with the session fixation bug?

2005-06-04 Thread Ben Laurie
https and PKI worthless against such man in the middle attacks. Have these bugs been addressed? On 20 May 2005 at 23:21, Ben Laurie wrote: Do they exist? Certainly any session ID I've ever had a hand in has two properties that strongly resist session fixation: a) If a session ID arrives

Re: Digital signatures have a big problem with meaning

2005-06-07 Thread Ben Laurie
Ian G wrote: On Wednesday 01 June 2005 15:07, [EMAIL PROTECTED] wrote: Ian G writes: | In the end, the digital signature was just crypto | candy... On the one hand a digital signature should matter more the bigger the transaction that it protects. On the other hand, the bigger the

Re: Digital signatures have a big problem with meaning

2005-06-07 Thread Ben Laurie
Anne Lynn Wheeler wrote: Peter Gutmann wrote: That cuts both ways though. Since so many systems *do* screw with data (in insignificant ways, e.g. stripping trailing blanks), anyone who does massage data in such a way that any trivial change will be detected is going to be inundated with

Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)

2005-06-08 Thread Ben Laurie
Perry E. Metzger wrote: Have a look, for example, at http://www.americanexpress.com/ which encourages users to type in their credentials, in the clear, into a form that came from lord knows where and sends the information lord knows where. Spoof the site, and who would notice? Every company

Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout Algorithm hiding ?)

2005-06-08 Thread Ben Laurie
Amir Herzberg wrote: 3. They did not actually spell out the problem in using SSL in the homepage (like eTrade, for instance). But I think I know the reason (they didn't confirm or deny). I think the reason is that they host their site; in particlar, when I tried accessing it via https, I got

Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)

2005-06-09 Thread Ben Laurie
[EMAIL PROTECTED] wrote: | Oracle, for example, provides encryption functions, but the real problem | is the key handling (how to make sure the DBA can't get the key, cannot | call functions that decrypt the data, key not copied with the backup, | etc.). | There are several solutions for the key

Re: AmEx unprotected login site

2005-06-09 Thread Ben Laurie
Perry E. Metzger wrote: Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going to them and not to someone who cleverly sent you an altered version of

Re: AmEx unprotected login site

2005-06-09 Thread Ben Laurie
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Steven M. Bellovin [EMAIL PROTECTED] writes: They're still doing the wrong thing. Unless the page was transmitted to you securely, you have no way to trust that your username and password are going

Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)

2005-06-13 Thread Ben Laurie
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: | Oracle, for example, provides encryption functions, but the real problem | is the key handling (how to make sure the DBA can't get the key, cannot | call functions that decrypt the data, key not copied with the backup, | etc.). | There are

Re: encrypted tapes (was Re: Papers about Algorithm hiding ?)

2005-06-13 Thread Ben Laurie
[EMAIL PROTECTED] wrote: Ben Laurie wrote [EMAIL PROTECTED] wrote: Example: Cash_Ur_check is in the business of cashing checks. To cash a check, they ask you for sensitive information like SIN, bank account number, drivers licence number, etc. They use the information to query Equifax

Optimisation Considered Harmful

2005-06-22 Thread Ben Laurie
A brief altercation this evening with CERT over the recent hyperthread caching issues has brought something that's been simmering at the back of my brain to the forefront. The recent hyperthread/cache key recovery trick, followed by DJB's related (IMO) symmetric key recovery, and preceded by

Re: WYTM - but what if it was true?

2005-06-22 Thread Ben Laurie
Allan Liska wrote: 3. Use an on-screen keyboard. For extra points, try Dasher. http://www.inference.phy.cam.ac.uk/dasher/ -- ApacheCon Europe http://www.apachecon.com/ http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can

Re: Optimisation Considered Harmful

2005-06-24 Thread Ben Laurie
Victor Duchovni wrote: On Thu, Jun 23, 2005 at 07:36:38AM -0400, Jerrold Leichter wrote: - Develop algorithms that offer reasonable performance even if implemented in unoptimized ways. This will be difficult to maintain in the face of ever-increasing

Re: the limits of crypto and authentication

2005-07-11 Thread Ben Laurie
Peter Gutmann wrote: [EMAIL PROTECTED] writes: Take a look at Boojum Mobile -- it is precisely the idea of using the cell phone as an out-of-band chanel for an in-band transaction. http://www.boojummobile.com Banks here have been using it to authenticate higher-value electronic

Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie
Perry E. Metzger wrote: Florian Weimer [EMAIL PROTECTED] writes: * Perry E. Metzger: Nick Owen [EMAIL PROTECTED] writes: It would seem simple to thwart such a trojan with strong authentication simply by requiring a second one-time passcode to validate the transaction itself in addition to

Re: EMV

2005-07-12 Thread Ben Laurie
Peter Fairbrother wrote: Florian Weimer wrote: * David Alexander Molnar: Actually, smart cards are here today. My local movie theatre in Berkeley, California is participating in a trial for MasterCard PayPass. There is a little antenna at the window; apparently you can just wave your card

Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: That could be fixed. I think the right design for such a device has it only respond to signed and encrypted requests from the issuing bank directed at the specific device, and only make signed and encrypted replies directed only

Re: the limits of crypto and authentication

2005-07-12 Thread Ben Laurie
Perry E. Metzger wrote: Anonymity is a concern to me, too, but I suspect that it is hard to get anonymity in a credit card transaction using current means, even if the merchant isn't online. Pseudonymity, perhaps. Can we not aim higher than merely doing as badly as current systems do? --

Re: the limits of crypto and authentication

2005-07-15 Thread Ben Laurie
Perry E. Metzger wrote: Ben Laurie [EMAIL PROTECTED] writes: Perry E. Metzger wrote: Anonymity is a concern to me, too, but I suspect that it is hard to get anonymity in a credit card transaction using current means, even if the merchant isn't online. Pseudonymity, perhaps. Can we not aim

Re: mother's maiden names...

2005-07-15 Thread Ben Laurie
Peter Gutmann wrote: Perry E. Metzger [EMAIL PROTECTED] writes: Why is it, then, that banks are not taking digital photographs of customers when they open their accounts so that the manager's computer can pop up a picture for him, which the bank has had in possession the entire time and which

Re: ID theft -- so what?

2005-08-14 Thread Ben Laurie
Ian Grigg wrote: Too many words? OK, here's the short version of why phising occurs: Browsers implement SSL+PKI and SSL+PKI is secure so we don't need to worry about it. PKI+SSL *is* the root cause of the problem. It's just not the certificate level but the business and architecture level.

Re: The summer of PKI love

2005-08-14 Thread Ben Laurie
Stephan Neuhaus wrote: Anne Lynn Wheeler wrote: http://www.infoworld.com/article/05/08/10/33OPstrategic_1.html The page goes on to say: One reason for PKI's slow uptake has been the lack of two kinds of portability. It hasn't been easy to move cryptographic keys from one machine to

Re: How many wrongs do you need to make a right?

2005-08-17 Thread Ben Laurie
Florian Weimer wrote: Can't you strip the certificates which have expired from the CRL? (I know that with OpenPGP, you can't, but that's a different story.) Yes, you can. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far

Re: Fwd: Tor security advisory: DH handshake flaw

2005-08-20 Thread Ben Laurie
Hal Finney wrote: I was just at Crypto yesterday and Hugo Krawczyk in his talk emphasized the difficulty of securely designing key exchange protocols. He was talking about implicit authorization protocols where the exponentiation involves the long term public key(s). This protocol is different

Re: Fwd: Tor security advisory: DH handshake flaw

2005-08-21 Thread Ben Laurie
Hal Finney wrote: Ben Laurie writes: Related to this is a project I keep considering and never quite getting around to is to include a prime proof verifier in OpenSSL. It would be pretty cool to have modes which only work when all relevant primes come with proofs. I've looked

Re: Fwd: Tor security advisory: DH handshake flaw

2005-08-22 Thread Ben Laurie
Jerrold Leichter wrote: | Apologies, slightly at cross-purposes here. For a start, Sophie Germain primes | are needed for D-H (or rather, safe primes), and secondly, I was talking about | proving arbitrary primes, rather than constructing provable primes. Isn't *proving* primality rather

  1   2   3   4   >