See below, which includes a handy pointer to the Microsoft and Mozilla
policy statements "requiring" CAs to cease signing anything shorter than
2048 bits.
As I think I said last week -- was it last week? -- it's my belief that
cutting everything on the Web over to 2048 bits rather than, say, 1280
Thor Lancelot Simon writes:
> a significant net loss of security, since the huge increase in computation
> required will delay or prevent the deployment of "SSL everywhere".
That would only happen if we (as security experts) allowed web developers to
believe that the speed of RSA is the limiting
Thor Lancelot Simon wrote:
> See below, which includes a handy pointer to the Microsoft and Mozilla
> policy statements "requiring" CAs to cease signing anything shorter than
> 2048 bits.
<...snip...>
> These certificates (the end-site ones) have lifetimes of about 3 years
> maximum. Who here thin
On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
> Thor Lancelot Simon writes:
>
> > a significant net loss of security, since the huge increase in computation
> > required will delay or prevent the deployment of "SSL everywhere".
>
> That would only happen if we (as security experts
On Sep 30, 2010, at 11:41 18AM, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>> Thor Lancelot Simon writes:
>>
>>> a significant net loss of security, since the huge increase in computation
>>> required will delay or prevent the deployment of "SSL ev
On 09/30/2010 10:41 AM, Thor Lancelot Simon wrote:
On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
Thor Lancelot Simon writes:
a significant net loss of security, since the huge increase in computation
required will delay or prevent the deployment of "SSL everywhere".
That woul
On Thu, 30 Sep 2010, Thor Lancelot Simon wrote:
That would only happen if we (as security experts) allowed web developers to
believe that the speed of RSA is the limiting factor for web application
performance.
At 1024 bits, it is not. But you are looking at a factor of *9* increase
in comput
On Thu, Sep 30, 2010 at 01:36:47PM -0400, Paul Wouters wrote:
[I wrote]:
>> Also, consider devices such as deep-inspection firewalls or application
>> traffic managers which must by their nature offload SSL processing in
>> order to inspect and possibly modify data
>
> You mean it will be harder fo
On 10-09-30 11:41 AM, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>> Thor Lancelot Simon writes:
>>
>>> a significant net loss of security, since the huge increase in computation
>>> required will delay or prevent the deployment of "SSL everywhere".
>>
On 30-09-2010 16:41, Thor Lancelot Simon wrote:
> On Wed, Sep 29, 2010 at 09:22:38PM -0700, Chris Palmer wrote:
>> Thor Lancelot Simon writes:
>>
>>> a significant net loss of security, since the huge increase in
>>> computation required will delay or prevent the deployment of
>>> "SSL everywhere"
On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
>
> One solution would be to use 2048-bit 4-prime RSA. It would maintain the
> security of RSA-2048, enable the reusing of the modular arithmetic units
> of 1024 bit VLSI chips and keep ECM factoring at bay. The added cost
> would only
On Thu, Sep 30, 2010 at 01:32:38PM -0400, Thor Lancelot Simon wrote:
> On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
> >
> > One solution would be to use 2048-bit 4-prime RSA. It would maintain the
> > security of RSA-2048, enable the reusing of the modular arithmetic units
> > of
On 30-09-2010 18:32, Thor Lancelot Simon wrote:
> On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
>> One solution would be to use 2048-bit 4-prime RSA. It would maintain the
>> security of RSA-2048, enable the reusing of the modular arithmetic units
>> of 1024 bit VLSI chips and keep
On Thu, Sep 30, 2010 at 01:32:38PM -0400, Thor Lancelot Simon wrote:
> On Thu, Sep 30, 2010 at 05:18:56PM +0100, Samuel Neves wrote:
> >
> > One solution would be to use 2048-bit 4-prime RSA. It would maintain the
> > security of RSA-2048, enable the reusing of the modular arithmetic units
> > of
Thor Lancelot Simon writes:
> > believe that the speed of RSA is the limiting factor for web application
>
> At 1024 bits, it is not. But you are looking at a factor of *9* increase
> in computational cost when you go immediately to 2048 bits.
In my quantitative, non-hand-waving, repeated exper
On 01-10-2010 02:41, Victor Duchovni wrote:
> Should we be confident that 4-prime RSA is stronger at 2048 bits than
> 2-prime is at 1024? At the very least, it is not stronger against ECM
> (yes ECM is not effective at this factor size) and while GNFS is not
> known to benefit from small factors,
On 2010-10-01 3:23 PM, Chris Palmer wrote:
In my quantitative, non-hand-waving, repeated experience with many clients in
many business sectors using a wide array of web application technology
stacks, almost all web apps suffer a network and disk I/O bloat factor of 5,
10, 20, ...
Which does not
17 matches
Mail list logo
