[I feel a little uncomfortable replying with such a wide distribution!]
Getting browsers, or OpenID installations, to check CRLs or use OCSP to
check for freshness is likely to be slow going. At this point I think
the momentum still favors fixing the remaining DNS systems that are
vulnerable to ca
* Eric Rescorla:
> Why do you say a couple of megabytes? 99% of the value would be
> 1024-bit RSA keys. There are ~32,000 such keys.
There are three sets of keys, for big-endian 32-bit, little-endian
32-bit and little-endian 64-bit. On top of that, "openssl genrsa"
generates different keys depen
| > You can get by with a lot less than 64 bits. People see problems
| > like this and immediately think "birthday paradox", but there is no
| > "birthday paradox" here: You aren't look for pairs in an
| > ever-growing set, you're looking for matches against a fixed set.
| > If you use 30-bit has
At Fri, 8 Aug 2008 15:52:07 -0400 (EDT),
Leichter, Jerry wrote:
>
> | > > Funnily enough I was just working on this -- and found that we'd
> | > > end up adding a couple megabytes to every browser. #DEFINE
> | > > NONSTARTER. I am curious about the feasibility of a large bloom
> | > > filter tha
On Fri, Aug 08, 2008 at 12:35:43PM -0700, Paul Hoffman wrote:
> At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
> >On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
> >> The kerberos style of having credentials expire very quickly is one
> >> (somewhat less imperfect) way to deal w
On Fri, Aug 8, 2008 at 7:54 PM, Tim Dierks <[EMAIL PROTECTED]> wrote:
> Using this Bloom filter calculator:
> http://www.cc.gatech.edu/~manolios/bloom-filters/calculator.html , plus the
> fact that there are 32,768 weak keys for every key type & size, I get
> various sizes of necessary Bloom filter
[Sorry for duplicates, but I got multiple requests for a non-HTML
version, and I didn't want to fork the thread. Also sorry for
initially sending HTML; I didn't realize it was so abhorrent these
days. ]
On Fri, Aug 8, 2008 at 1:43 PM, Dan Kaminsky <[EMAIL PROTECTED]> wrote:
>>
>> It's easy to comp
| > > Funnily enough I was just working on this -- and found that we'd
| > > end up adding a couple megabytes to every browser. #DEFINE
| > > NONSTARTER. I am curious about the feasibility of a large bloom
| > > filter that fails back to online checking though. This has side
| > > effects but pe
On Fri, Aug 8, 2008 at 8:27 PM, Eddy Nigg (StartCom Ltd.)
<[EMAIL PROTECTED]> wrote:
> Ben Laurie:
>
> On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.)
> <[EMAIL PROTECTED]> wrote:
>
>
> This affects any web site and service provider of various natures. It's not
> exclusive for OpenID nor
I just got called by an autodialer -- the Caller ID was faked (and in
any case didn't point at a real number since area codes don't start
with "0" -- probably a mistake by the scammers).
After I answered, a tape of a cheerful woman informed me this was my
"last chance to lower the rate on my cred
At 1:47 PM -0500 8/8/08, Nicolas Williams wrote:
On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
The kerberos style of having credentials expire very quickly is one
(somewhat less imperfect) way to deal with such things, but it is far
from perfect and it could not be done fo
On Fri, Aug 08, 2008 at 11:20:15AM -0700, Eric Rescorla wrote:
> At Fri, 08 Aug 2008 10:43:53 -0700,
> Dan Kaminsky wrote:
> > Funnily enough I was just working on this -- and found that we'd end up
> > adding a couple megabytes to every browser. #DEFINE NONSTARTER. I am
> > curious about the f
On Fri, Aug 08, 2008 at 02:08:37PM -0400, Perry E. Metzger wrote:
> The kerberos style of having credentials expire very quickly is one
> (somewhat less imperfect) way to deal with such things, but it is far
> from perfect and it could not be done for the ad-hoc certificate
> system https: depends
At Fri, 08 Aug 2008 10:43:53 -0700,
Dan Kaminsky wrote:
> Eric Rescorla wrote:
> > It's easy to compute all the public keys that will be generated
> > by the broken PRNG. The clients could embed that list and refuse
> > to accept any certificate containing one of them. So, this
> > is distinct from
"Ben Laurie" <[EMAIL PROTECTED]> writes:
>> It's easy to compute all the public keys that will be generated
>> by the broken PRNG. The clients could embed that list and refuse
>> to accept any certificate containing one of them. So, this
>> is distinct from CRLs in that it doesn't require knowing
Eric Rescorla <[EMAIL PROTECTED]> writes:
>It's easy to compute all the public keys that will be generated
>by the broken PRNG. The clients could embed that list and refuse
>to accept any certificate containing one of them. So, this
>is distinct from CRLs in that it doesn't require knowing
>which
Eric Rescorla wrote:
At Fri, 8 Aug 2008 17:31:15 +0100,
Dave Korn wrote:
Eric Rescorla wrote on 08 August 2008 16:06:
At Fri, 8 Aug 2008 11:50:59 +0100,
Ben Laurie wrote:
However, since the CRLs will almost certainly not be checked, this
means the site will still be vulnerabl
On Fri, Aug 8, 2008 at 5:57 PM, Eric Rescorla <[EMAIL PROTECTED]> wrote:
> At Fri, 8 Aug 2008 17:31:15 +0100,
> Dave Korn wrote:
>>
>> Eric Rescorla wrote on 08 August 2008 16:06:
>>
>> > At Fri, 8 Aug 2008 11:50:59 +0100,
>> > Ben Laurie wrote:
>> >> However, since the CRLs will almost certainly n
Eric Rescorla wrote on 08 August 2008 17:58:
> At Fri, 8 Aug 2008 17:31:15 +0100,
> Dave Korn wrote:
>>
>> Eric Rescorla wrote on 08 August 2008 16:06:
>>
>>> At Fri, 8 Aug 2008 11:50:59 +0100,
>>> Ben Laurie wrote:
However, since the CRLs will almost certainly not be checked, this
mea
On Fri, 8 Aug 2008, Dave Korn wrote:
| > Isn't this a good argument for blacklisting the keys on the client
| > side?
|
| Isn't that exactly what "Browsers must check CRLs" means in this
| context anyway? What alternative client-side blacklisting mechanism
| do you suggest?
Since the list of bad
At Fri, 8 Aug 2008 17:31:15 +0100,
Dave Korn wrote:
>
> Eric Rescorla wrote on 08 August 2008 16:06:
>
> > At Fri, 8 Aug 2008 11:50:59 +0100,
> > Ben Laurie wrote:
> >> However, since the CRLs will almost certainly not be checked, this
> >> means the site will still be vulnerable to attack for th
Eric Rescorla wrote on 08 August 2008 16:06:
> At Fri, 8 Aug 2008 11:50:59 +0100,
> Ben Laurie wrote:
>> However, since the CRLs will almost certainly not be checked, this
>> means the site will still be vulnerable to attack for the lifetime of
>> the certificate (and perhaps beyond, depending on
Quoting:
New microchipped passports designed to be foolproof against
identity theft can be cloned and manipulated in minutes and
accepted as genuine by the computer software recommended for use
at international airports.
Tests for The Times exposed security flaws in the micro
At Fri, 8 Aug 2008 11:50:59 +0100,
Ben Laurie wrote:
> However, since the CRLs will almost certainly not be checked, this
> means the site will still be vulnerable to attack for the lifetime of
> the certificate (and perhaps beyond, depending on user
> behaviour). Note that shutting down the site D
| > | My theory is that no actual security people have ever been involved,
| > | that it's just another one of those stupid design practices that are
| > | perpetuated because "nobody has ever complained" or "that's what
| > | everybody is doing".
| >
| > Your theory is incorrect. There is conside
On Fri, Aug 8, 2008 at 12:44 PM, Eddy Nigg (StartCom Ltd.)
<[EMAIL PROTECTED]> wrote:
> This affects any web site and service provider of various natures. It's not
> exclusive for OpenID nor for any other protocol / standard / service! It may
> affect an OpenID provider if it uses a compromised key
From an article about WAN optimization appliances in Computerworld:
In some markets, such as health and finance, [hiring] a managed
provider [who will do the encryption "outside" your routers] isn't a
good option for another reason: Because data is optimized in an
unencrypted state
Security Advisory (08-AUG-2008) (CVE-2008-3280)
===
Ben Laurie of Google's Applied Security team, while working with an
external researcher, Dr. Richard Clayton of the Computer Laboratory,
Cambridge University, found that various OpenID Providers (OPs) h
[EMAIL PROTECTED] wrote:
John Ioannidis wrote:
| Does anyone know how this "security questions" disease started, and
why
| it is spreading the way it is? If your company does this, can you
find
| the people responsible and ask them what they were thinking?
The answer is "Help Desk Call Avoid
29 matches
Mail list logo
