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?
block SHA-1's a
second. So, multiply that by 5 million to get it down to 17 years,
assuming all you have to do is hash.
Of course, we don't have the details yet, but this is not the sky
falling on our heads (yet).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebun
o this for
Mercedes - does anyone know what they use in their keys (they aren't
RFID for the relevant models, they're the more traditional infrared kind)?
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 f
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
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 outp
John Denker wrote:
Ben Laurie wrote:
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
I just took a look at the first coupl
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.
--
http://
C. Scott Ananian wrote:
On Wed, 22 Dec 2004, Ben Laurie wrote:
Blimey. Finally. An attack I can actually believe in. Excellent
John Kelsey wrote:
From: Ben Laurie <[EMAIL PROTECTED]> Sent: Dec 22, 2004 12:24 PM
To: David Wagner <[EMAIL PROTECTED]> Cc:
cryptography@metzdowd.com Subject: Re: The Pointlessness of the MD5
"attacks"
...
Assuming you could find a collision s.t. the resulting decryptio
James A. Donald wrote:
--
On 15 Dec 2004 at 8:51, Ben Laurie wrote:
People seem to be having a hard time grasping what I'm trying
to say, so perhaps I should phrase it as a challenge: find me
a scenario where you can use an MD5 collision to mount an
attack in which I could not mount an eq
David Wagner wrote:
Ben Laurie writes:
Indeed, but what's the point? If you control the binary, just distribute
the malicious version in the first place.
Where this argument breaks down is that someone might have partial
but not total control over the binary. This partial control might
n
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 thi
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 is
ta encrypted or some such. There are lots of easy ways to get your
maliciousness past a black-box test. The use of MD5 (a relatively
*hard* way to be malicious) doesn't appreciably change the threat.
Exactly so, thankyou.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.t
just becomes a lot less valuable.
I do not have a special reason to think anything about future attacks on
MD5. I am discussing the present attacks.
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 g
we can have people review 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 ch
inspected or being sufficiently cunning that inspection didn't help.
And, if that's the case, the attacks work without any MD5 trickery.
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
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
.
Quite so, but the "desired change to source" is either not visible, or
suspicious. If it's not visible, then just make it malicious. And if
it's suspicious then it shouldn't be run.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There
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 t
is 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 to
find out whether to mi
> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 01, 2004 7:01 AM
> To: [EMAIL PROTECTED]
> Cc: Ben Nagy; [EMAIL PROTECTED]
> Subject: Re: SSL/TLS passive sniffing
>
> "Ian Grigg" <[EMAIL PROTECTED]>
mind is forward secrecy.
Yes and no. Forward secrecy is certainly at the root of my question, with
regards to the RSA modes not providing it and certain of the DH modes doing
so. :)
Thanks!
ben
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
n DH
- sure you only authenticate one side of the connection, but who cares? Was
it simply to save one setup packet?
Anyone know?
Cheers,
ben
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
ct. Because of the capabilities, the
TTP could run the code without fear, and you would both know that it
performed the desired function, but neither of you could subvert it.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.t
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
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 tha
r as premoderators), but are not on ukcrypto because of the
volume. Please feel free to forward this to other lists/individuals that
might be interested.
Pre-moderators, please apply directly to me.
Discussion/questions can go wherever you prefer.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http:
I'd suggest going somewhere without surveillance
cameras, buying a printer for cash, using it and then destroying it.
Don't forget not to use your car and leave your mobile phone behind. Oh,
and take the RFID tags out of your clothes.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http:
to the slower of the two. Of course, for some threat
models that would be the right thing.
Cheers,
Ben.
--
ApacheCon! 13-17 November! 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
Peter Gutmann wrote:
Ben Laurie <[EMAIL PROTECTED]> writes:
Oh yeah, another gem from the eVAT FAQ:
"The Government Gateway and Digital Certificate authorities do not currently
support the use of Digital Certificates on Apple Macintosh"
Well, of course not, because everyone knows
e knows that Apple X.509 is
completely different from Microsoft X.509. Duh.
So, after all that, I totally understand why everyone thinks PKI is
hard. I'm all for the username/password thing. Its free, too.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apach
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
require
ailable to third parties without the consent of
the sender, is it not?
It seems to me that fixing the PK "problem" would in no way improve the
senders situation given that threat model.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apache-s
h to keep their CPU
pools filled?
We have some figures for that kind of stuff in
http://www.apache-ssl.org/proofwork.pdf.
Cheers,
Ben.
--
ApacheCon! 13-17 November! http://www.apachecon.com/
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can
this would lead to
finding many collisions easily, including to messages with random
prefixes, this could be more worrying...
Hmmm ... if you could persuade your victim to use a key that was known
to be a suitable prefix for finding collisions...
Cheers,
Ben.
--
http://www.apache-ssl.org
L, IIRC, sets the top and bottom
bits to 1. Of course, all large primes have the bottom bit set to one.
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
osoft
cryptographic providers is o.k.
That's if you think FIPS 186 is OK, which by many standards, it is not
(I had occasion to look at it closely when doing FIPS 140 for OpenSSL).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what
systems where
there's no attacker specifically targeting you" prompted me to ask this
... if a system claims to give you anonymity, how do you (as a user)
assess that claim? I find it hard to imagine how you can even know
whether it "seems to work", let alone has some subtl
[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&
efore intrusions can occur again.
What you _may_ have shown is that there's an infinite number of bugs in
any particularly piece of s/w. I find that hard to believe, too :-)
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a m
[EMAIL PROTECTED] wrote:
And of course, the article didn't get it right. Because of optimizing
compilers, it is *not* trivial to zero passwords.
In OpenSSL we overwrite with random gunk for this reason.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
&quo
Ian Brown wrote:
This reminds me of a question I've been meaning to ask for a while. Has
there been any research done on encryption systems which encrypt two
(or
n) plaintexts with n keys, producing a joint ciphertext with the
property that decrypting it with key k[n] only produces the
nth pla
proof-of-work cannot be a complete solution in itself. We will be making
that clearer in a revision of the paper (and fixing some errors).
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
dows is a petri dish.
Duh. So viruses would fix the stack.
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
---
rypto (because its moderated) mailing lists, rather
than competitive with them.
And no, I'm not interested in discussing why we haven't burnt our money
buying a cert from your favourite money sink.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"
, just like PK encryption is. MACs and MDs (if
keyed at all) use a shared secret, and thus behave like symmetric crypto.
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
My co-author (a lawyer) responds in detail to Ian Grigg's criticisms.
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 Woodru
nly receive 144
spams per day. That's a significant improvement on my situation.
Plus I'd've thought that having 100% CPU utilisation all the time might
attract attention. But maybe not.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There
stamp that you generated. Each subscruber adds
[EMAIL PROTECTED] as an address they receive mail at. Done. Trivial.
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
itive description, not the formal specifications.
What you have here is evidence of origin, not non-repudiation.
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 cr
so the signer here must be a human or
organization rather than a key. It is that unjustifiable linkage from the
actions of a key to the actions of one or more humans that needs to be
eradicated from the literature.
This is going a little far, isn't it? If the human controls the setting
of the
amounts to that contract is extremely dangerous, and might even
be seen as an attempt to victimize a whole class of consumers.
Agreed - as I say, its all about intent and reliance. Nothing is automatic.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There
Also it's an unavoidable
fact of life (imho) that other communities (e.g. legal) use the same
term in somewhat different meaning.
So my question is only to people like Ben and Carl who have expressed,
if I understood correctly, objection to any form of technical, crypto
definition of non-r
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
cry
Raymond Lillard wrote:
Ben Laurie wrote:
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
is much smaller (estimated to be a factor
of 4 from slowest to fastest PCs, for example).
BTW, for those who don't know, SpamAssassin now supports hashcash.
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 fa
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/
&quo
um. You want them on your box, and they want them not to leave your box.
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
.
Probably because non-repudiation is a stupid idea:
http://www.apache-ssl.org/tech-legal.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 can go if he
doesn't mind who gets the credit." -
hat smartcard goes through a normal device
driver to access its machine).
I'm not arguing with this - just the economic argument about number of
smartcards.
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
nt past me again?
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
-
[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 de
[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 pri
_Key2)
Receiver's Algorithm
3DES_Key2 = RSA_Private_Decrypt(RSA_Key2)
Cipher1 = 3DES_Decrypt(Cipher2)
Digest || 3DES_Key1 = RSA_Public_Decrypt(RSA_Key1)
message = 3DES_Decrypt(Cipher1)
Compare Digest with SHA1(message)
I don't see any value added by cipher1 - what's the point?
Ch
anted.
The list can be found here:
https://mailman.aldigital.co.uk/mailman/listinfo/vpn (yes, I know the
certificate has expired).
It will also be reflected into news at gmane.network.vpn.theory.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is n
ve firewalling, and
that's what you really want for a VPN.
> If someone out there wants to write VPN software that becomes widely used,
> then they should make a free IP-over-TCP solution that works on Windows
> and Linux which uses password authentication.
Doesn't OpenVPN have
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:
&g
erely replacing the TLS part
doesn't actually help most people.
Anyway, that said, there's certainly room for something that does
everything OpenSSL does, only nicely.
Cheers,
Ben.
[1] People have wondered in the past why I maintain OpenSSL if I have
such a low opinion of it - the an
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 anythi
ingle generally-usable version being certified.
Which is, of course, what we are trying to fix. And yeah, there are
others using OpenSSL. And if they don't say so, they're in breach of the
licence.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"
you really mean ASN.1 or do you mean DER/BER?
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
---
own the
> state of a partially completed connection at any time without memory leaks
> or other problems.
Again, you can do this with OpenSSL.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunke
V_FLAG_CRL_CHECK_ALL;
X509_STORE_set_flags(pStore,vflags);
}
(note, before people start nagging me for it, this is a WIP, but will be
released soon).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do
140 certification is not
> entirely accurate.
My fault. RSA is not validated (there are no validation tests for it),
but it will be in the code we are submitting for certification.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what
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 gu
that it has the real guy online (without
playing nasty tricks with the guts of SSL, anyway), and there's
certainly no way to prove that some particular response came from him.
Signing stuff would deal with this trivially.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.
> library was ok. It had to be turned into a DLL at the last moment (i.e.
> during the review phase).
This is all good fun, coz I'm mandating static libraries for OpenSSL, so
that the evidential chain can be maintained (its hard to find a DSO in a
cross-platform manner so you can checksum
utable, or verify the entire resulting executable.
I disagree. OpenSSL has a check of authenticity that works with static
libraries and linking only some of the module. I'll shout to this list
when I've written down exactly how the process works (or you can look at
CVS, coz I checked it in thi
extend it
> to more random bytes. But FIPS-140-2 has no
> provision for generating the seed in the first place,
> this is where something like Yarrow or the cryptlib
> RNG come in handy.
Actually, FIPS-140 _does_ have provision for seeding, at least for X9.17
(you use the time :-)
-2 certified.
The validation is for the source of OpenSSL, and will be rolled into the
release, this is what is new.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or
become quite easy to do if you trust an introducer to tell you where to go.
BTW, tell me how you do spoofing and MITM if you aren't the trusted
introducer (if you are, clearly there's no need to spoof or MITM,
because you can just give the target of your choice)?
Cheers,
Ben.
--
http:
become quite easy to do if you trust an introducer to tell you where to go.
What is a CA other than an introducer?
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 h
James A. Donald wrote:
> --
> James A. Donald wrote:
>
>>>This flaw is massive, and the biggest villain is the server
>>>side code created for Apache.
>
>
> Ben Laurie
>
>>This isn't the case. I analysed several sites I work on for
>
environments.
This isn't the case. I analysed several sites I work on for attacks of
the type described when this paper first came out. None of them were
vulnerable.
I suggest you read and think more carefully.
I will agree that an incautious implementor could get bitten by
/.
Anyone actually using it for anything vaguely serious is advised to upgrade.
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." -
ur methods.)
Errr... it was a Psion, and they have keyboards.
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
--
301 - 387 of 387 matches
Mail list logo
