erhaps not been clear in some of my comments in this thread. I
think there is a world of difference between critical errors and
detecting internal inconsistency. In the case of inconsistency I claim
that it is _never_ correct to continue running because every instruction
executed is another poten
Paul Hoffman wrote:
> At 5:40 PM + 2/12/06, Ben Laurie wrote:
>> It also defends against the MD5 crack, and is one of the recommended
>> IETF solutions to hash problems.
>
> s/recommended/proposed/
>
> The IETF has not recommended any "solutions to hash probl
Travis H. wrote:
> On 2/8/06, Jack Lloyd <[EMAIL PROTECTED]> wrote:
>> An obvious example occurs when using a
>> deterministic authentication scheme like HMAC - an attacker can with high
>> probability detect duplicate plaintexts by looking for identical tags.
>
> I think though that the solution
Victor Duchovni wrote:
> On Fri, Feb 10, 2006 at 07:49:59PM +0000, Ben Laurie wrote:
>
>> Secondly, obviously, you can only decrypt SSL if you have the private
>> key, so presumably this is referring only to incoming SSL connections.
>>
>
> And only if EDH (or more
t can't produce that random
> - what shall we do else than abort the process. This way the errors
> will be detected before major harm might occur.
>
> It is the same rationale why defining NDEBUG in production code is a
> Bad Thing.
I agree.
Cheers,
Ben.
--
http://w
I co-authored
on this and other stuff - executive summary: I don't believe it), you
can't "maintain" the non-repudation of SSL because it doesn't provide
non-repudation.
Secondly, obviously, you can only decrypt SSL if you ha
f you'd prefer not to be hit, being able to prove you
decrypted everything might be a good idea.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
itwise differences on successive reads,
much to my surprise, so if you want to do this, remember to include
error correction :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no li
George Danezis and I wrote a paper describing a technique for private,
yet abuse-resistant, publishing. Here’s the abstract:
We present the problem of abusive, off-topic or repetitive
postings on open publishing websites, and the difficulties
associated with filtering them out. We prop
t; that key, which is little to none anyway.
So that you can't be legally required to produce the private key (which
you destroyed, right?).
Perhaps this is time to remind people of "Security Against Compelled
Disclosure": http://www.apache-ssl.org/disclosure.pdf.
Cheers,
B
Steven M. Bellovin wrote:
> In message <[EMAIL PROTECTED]>, Ben Laurie writes:
>> Bill Frantz wrote:
>>> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote:
>>>
>>>> I don't see why not - the technical details actually matter. Since the
&
Bill Frantz wrote:
> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote:
>
>> I don't see why not - the technical details actually matter. Since the
>> servers will all share a socket, on any normal architecture, they'll all
>> have access to everyone's pri
Adam Back wrote:
> On Tue, Jan 03, 2006 at 10:10:50PM +0000, Ben Laurie wrote:
>> Jack Lloyd wrote:
>>> Some relevant and recent data: in some tests I ran this weekend
>>> [gmp faster than openssl]
>>> AFAIK blinding alone can protect against all (publicly k
any other platforms, is simply a question of which library has
hand-optimised assembler for the platform. That is, it tells us little
about architectural differences and plenty about whether anyone has been
bothered to optimise for that particular platform recently.
Cheers,
Ben.
--
http://www.apac
private keys.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
--
David Malone wrote:
> On Tue, Dec 27, 2005 at 03:26:59AM -0600, Travis H. wrote:
>> On 12/26/05, Ben Laurie <[EMAIL PROTECTED]> wrote:
>>> Surely if you do this, then there's a meet-in-the middle attack: for a
>>> plaintext/ciphertext pair, P, C, I choose rand
on't solve the problem that it
is hard to check the URL even the first time.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind wh
Jack Lloyd wrote:
> On Fri, Dec 16, 2005 at 05:41:48PM +0000, Ben Laurie wrote:
>
>> No, OpenSSL is self-contained. There is, IIRC, an engine that uses GMP
>> if you want, but its entirely optional; OpenSSL has its own bignum
>> implementation that's just as good.
&g
m
> permutation would help you at all.
Having shot myself in the foot once already, I've hesitated over
responding to this, but...
Surely if you do this, then there's a meet-in-the middle attack: for a
plaintext/ciphertext pair, P, C, I choose random keys to encrypt P and
decrypt C.
ly valid SSL domain name digital certificates ... and it doesn't
> stop the MITM-attack and/or phishing.
Eh? It surely does stop MitM attacks - the problem is that there's
little value in doing so for various reasons, such as no strong binding
between domain name and owner, UI that doesn
Ian G wrote:
> Ben Laurie wrote:
>> Ian G wrote:
> ...
>>> http://wiki.cacert.org/wiki/VhostTaskForce
>
>>> (The big problem of course is that you can use
>>> one cert to describe many domains only if they
>>> are the same administrative entity
Eric Rescorla wrote:
> Ben Laurie <[EMAIL PROTECTED]> writes:
>>> And we need SSL v2 to die so it doesn't interfere
>>> with the above.
>> Actually, you just disable it in the server. I don't see why we need
>> anything more than that.
>
>
Ian G wrote:
> Ben Laurie wrote:
> ...
>>> Hopefully over the next year, the webserver (Apache)
>>> will be capable of doing the TLS extension for sharing
>>> certs so then it will be reasonable to upgrade.
>>
>>
>> In fact, I'm told (I'
Ian G wrote:
>
>> BTW, illustrating points made here, the cert is for
>> financialcryptography.com
>> but your link was to www.financialcryptography.com. So of course Firefox
>> generated a warning
>
> Indeed and even if that gets fixed we still have
> to contend with:
>
> * the blog
Matt Crawford wrote:
> On Dec 21, 2005, at 0:10, Ben Laurie wrote:
>> Good ciphers aren't permutations, though, are they? Because if they
>> were, they'd be groups, and that would be bad.
>
> A given cipher, with a given key, is a permutation of blocks. (Assuming
&
Jack Lloyd wrote:
> On Mon, Dec 12, 2005 at 12:20:26AM -0600, Travis H. wrote:
>> 2) While CTR mode with a random key is sufficient for creating a
>> permutation of N-bit blocks for a fixed N, is there a general-purpose
>> way to create a N-bit permutation, where N is a variable? How about
>> pick
James A. Donald wrote:
> --
> "James A. Donald"
>>> Let us imagine that SSH had certified keys. Well,
>>> certifying a key is bound to be complicated, and
>>> things are bound to go wrong, and the name that you
>>> bind it to is bound t
James A. Donald wrote:
> --
> From: Ben Laurie <[EMAIL PROTECTED]>
>
>>if the key changes in OpenSSH you can't connect until
>>you take positive action by deleting the old key from
>>the known_hosts file. This is totally different to
&g
[EMAIL PROTECTED] wrote:
> | > | > My question is, what is the layperson supposed to do, if they must
> use
> | > | > crypto and can't use an off-the-shelf product?
> | > |
> | > | When would that be the case?
> | > |
> | > | The only defensible situations I can think of in which a
> | > | non-cr
David Mercer wrote:
>>>Horrible, horrible UI, and I'm not sure what's worse, that or trying
>>>to USE pgp (gpg, whatever) from a command line, or getting it
>>>integrated into a gui mail client.
>>
>>Two words: Thunderbird, enigmail.
>
>
> Sorry, I've become totally addicted to gmail and just can
David Mercer wrote:
> And my appologies to Ben Laurie and friends, but why after all these
> years is the UI interaction in ssh almost exactly the same when
> accepting a key for the first time as overriding using a different one
> when it changed on the other end, whether from mi
[EMAIL PROTECTED] wrote:
> On Mon, 12 Dec 2005, Steve Furlong wrote:
> | > My question is, what is the layperson supposed to do, if they must use
> | > crypto and can't use an off-the-shelf product?
> |
> | When would that be the case?
> |
> | The only defensible situations I can think of in whic
Will Morton wrote:
> Eric Rescorla wrote:
>>
>> May I ask why you don't just use TLS?
>>
>
> I would if I could, believe me. :o)
>
> The negotiated key will be used for both reliable (TCP-like) and
> non-reliable (UDP-like) connections, all tunnelled over a single UDP
> port for NAT-busting purpo
Terence Joseph wrote:
> Hi,
>
> The Pseudorandom Number Generator specified in Ansi X9.17 used to be one
> of the best PRNGs available if I am correct.
It was? When? I had to replace the OpenSSL PRNG with X9.31 (as has been
discussed elsewhere, this is the same PRNG) for the FIPS-140
certificatio
R. A. Hettinga wrote:
> In its application, Apple describes a means of securing code using
> either a specific hardware address or read-only memory (ROM) serial
> number. Apple also talks about securing the code while interchanging
> information among multiple operating systems. Mac OS X, W
y making all packets meaningful. You can find it here:
http://www.cl.cam.ac.uk/users/gd216/minx.pdf.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he c
At EuroOSCon, Rachel Willmer and I announced OpenPGP:SDK, a BSD-licensed
C library implementing the OpenPGP standard. The SDK is sponsored by
Nominet.
Although we are still very much in beta, feedback will be appreciated.
Permalink: http://www.links.org/?p=20
Cheers,
Ben.
--
http
...can be found here... http://www.links.org/?p=19. I'd quote it, but it
won't render well in plain ASCII.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind
Weger, B.M.M. de wrote:
> Hi Ben,
>
> Looks like this is essentially the same as, or at least very similar to,
>
> what Arjen Lenstra and I did in Section 4 of the full version of our
> paper
> "On the possibility of constructing meaningful hash collisions for
primes.
Code and stuff will follow, but now I'm going to bed. I expect its
obvious how they are made, anyway.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who
Steven M. Bellovin wrote:
> As Eric Rescorla and I showed, though, none of the network protocols
> are ready for deployment of a new hash function. That is, newer
> versions of OpenSSL support may SHA-256, but there's no way to
> negotiate such usage if you don't know the status of the system t
ld be that the NSA has to approve of the particular
piece of s/w.
Incidentally, why the focus on GPL?
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who
Adam Shostack wrote:
On Sat, Sep 17, 2005 at 11:40:26AM -0400, Victor Duchovni wrote:
| On Sat, Sep 17, 2005 at 11:53:20AM +0100, Ben Laurie wrote:
|
| > >My view is that C is fine, but it needs a real library and programmers
| > >who learn C need to learn to use the real libra
f we could all agree on a
single such library? Or at least, a single API. Like the STL is for C++.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who
Perry E. Metzger wrote:
What the world really needs is something between C++ and C -- a
language with very clean obvious semantics (like C) which does run
time bounds checking and strong typing, though it also needs explicit
escapes in the type system so you can write things like device drivers
i
Alexander Klimov wrote:
On Sun, 11 Sep 2005, Ben Laurie wrote:
Alexander Klimov wrote:
ECC is known since 1985 but seems to be absent in popular free
software packages, e.g., neither gnupg nor openssl has it (even if the
relevant patches were created). It looks like the main reason is some
Alexander Klimov wrote:
Hi.
ECC is known since 1985 but seems to be absent in popular free
software packages, e.g., neither gnupg nor openssl has it (even if the
relevant patches were created). It looks like the main reason is some
patent uncertainty in this area.
An internet research shows tha
ey're handed a number that is
supposedly prime, they're pretty safe.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the c
I've revised the graphics somewhat, in light of comments received. Now
shown are the input used in each round, and breaks between input blocks.
Same place: http://www.shmoo.com/md5-collision.html.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
&quo
Simon Josefsson wrote:
No, the certificate is verifiable in deterministic polynomial time.
The test is probabilistic, though, but as long as it works, I don't
see why that matters. However, I suspect the ANSI X9.80 or ISO 18032
paths are more promising. I was just tossing out URLs.
Surely Mil
Simon Josefsson wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
So Miller-Rabin is good for testing random candidates, but it is easy to
maliciously construct an n that passes several rounds of
Miller-Rabin.
Interesting! So how does one go about constructin
Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, Ben Laurie writes:
I wrote some code to show the internal state of MD5 during a collision...
http://www.shmoo.com/md5-collision.html
Very nice, though you need to give a scale of rounds -- how many
horizontal lines per
Shawe-Taylor, which is similar in functioning but only reaches 10% of all
primes of a specified set).
I presume you mean densely distributed over the set of all primes?
Uniform distribution isn't much use if its sparse!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
I wrote some code to show the internal state of MD5 during a collision...
http://www.shmoo.com/md5-collision.html
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind wh
Jerrold Leichter wrote:
| > Isn't *proving* primality rather overkill for the purpose at hand (which
| > seems to be verifying that an alleged prime isn't a non-prime, sent to
| > "spike" the system). Are there any known sets of numbers - much less ways
| > to *choose* members of those sets - wh
Tero Kivinen wrote:
Hal Finney writes:
Several programs to implement ECPP can be found from
http://primes.utm.edu/links/programs/seeking_large_primes/. I don't
know about source code however. It might be interesting to run these
over some of the Oakley primes and publish the certs - I vaguely
gument from a closed source prover and
verifier. Hmm.
The point of proofs (at least, useful proofs) is that they produce
certificates that are cheap to verify. So, yeah, sure it may be
overkill, but I'll do the killing so you don't have to.
Cheers,
Ben.
--
http://www.apache-ssl.
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 into t
around to implementing.
Oh, BTW, bonus points if the prover can be run on large numbers of
processors in parallel. Even more points if communication between the
CPUs are low bandwidth.
It would also be nice to have a collection of primes and proofs in
OpenSSL, so if people want t
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
sh.
And this doesn't use the property above. It uses a stronger type of
collision (i.e. a collision of internal state) - this allows s to be
chosen freely.
Cheers,
Ben.
--
ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/ben.html
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 ano
ss and
architecture level. The *people* equation.
PKI+SSL does not _cause_ the problem, it merely fails to solve it. You
may as well blame HTTP - in fact, it would be fairer.
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
ht
cheque and forgotten about it). Their response was
that they didn't know and had no way to find out. In the end they faxed
me a copy so I could check it myself.
Cheers,
Ben.
--
>>>ApacheCon Europe<<< http://www.apachecon.com/
http://www.apache-ssl.org/b
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.
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?
--
>>>Ap
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 o
the
contactless system alters this risk in any way?
Cheers,
Ben.
--
>>>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 do or how far he can go
g party has to let the
issuing bank come between it and you to get anywhere. This would
preclude, for example, offline transactions.
As I've said before, I totally agree that the only way to go is to have
signatures made on such a device, but I do think its very important to
design th
;ve paid an arm and a leg for it themselves, sigh.
Back when we used to run O2's (then Cellnet) web stuff, we used to
authenticate user accounts by sending random words to their phone. This
was so long ago I can't remember when it was, but certainly > 5 years.
Cheers,
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
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
ry_
hard to do.
Could it be that for safe crypto we should be using Z80s?
Cheers,
Ben.
[1] For those who don't know, even old Pentia have several different
processing units internally, which run in parallel. They can even tell
when instructions in one's pipeline conflict with an
h the user at all times and be secure.
Cheers,
Ben.
--
>>>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 do or how far he can go if he
doesn't mi
[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
[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 sev
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 user
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 o
[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
Perry E. Metzger wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
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 informatio
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 an
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 s
ould implement it correctly.
Sadly, experience shows that no-one can.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit."
people of my paper "Signatures:
an Interface between Law and Technology" (written with Nicholas Bohm, a
lawyer) which discusses this and other issues.
http://www.apache-ssl.org/tech-legal.pdf
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"Ther
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 ar
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 aga
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
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 http://www.thebunk
that you advise your correspondant to discontinue this line
of enquiry - for their own good and that of the aid community at large. "Not
getting caught" is a derivation of "the ends justify the means".
ben
> -Original Message-
> From: [EMAIL PROTECTED]
>
one required to
get those properties, I should point out.
I will confess that I have punted on whether those properties are
actually useful.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
d
equire a single pass (but, unfortunately, two or three
different instances of the hash). This seems similar to the mechanism
used in MD2, except the checksum is expensive.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or h
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 for the
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
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)
Barney Wolff wrote:
On Mon, Mar 21, 2005 at 11:56:44AM +, Ben Laurie wrote:
Musing on these points, I wondered about the construction:
H'(x)=H(H(x) || H(H(x) || x))
which doesn't allow an attacker any choice, doesn't change APIs and
doesn't change the length of the hash
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
e the length of the hash. Does this have any merit? Note
that this is essentially an HMAC where the key is H(x). I omitted the
padding because it seems to me that this actually makes HMAC weaker
against the current attacks.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.the
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.
--
http://www.apache
. Generating colliding
public keys takes quite a bit more work.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." -
al to your colliding
block, as he claims. However, you can (according to the paper above)
generate collisions with any IV, so if you know what the prepended
material is, then Kaminsky's attack will still work.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
&qu
201 - 300 of 387 matches
Mail list logo
