I am very far from being a mathematician, but Christian Huitema's
comments and analysis on this thread seem sensible to me.
Ran
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/
I want to table this discussion until I have the opportunity to code and
implement software that will prove what it is that I am trying justify. I
have just arrived home from the USA and Sunday I leave for another weeks'
conference. Once I return from that conference I will have the opportunity
to
On 03/22/2013 02:47 PM, Christian Huitema wrote:
> Pick two prime numbers from the catalog
> Multiply the two numbers to get a candidate RSA key
> Check whether the resulting pattern matches the 48 bits in the IID
I think you can be quicker than that. Generating primes is easy
Christian,
>
> I would not construct the attack by trying random numbers and checking them
> for whether they are a public key. I would start with a repository of prime
> numbers, and then do something like:
>
I agree with this as well.
Jari
-
> For the scheme in this draft，
> the probability of a a second public key is: 1-(1-p)^(2^{1024-48}), where p
>is the probability of a random number being a RSA public key.
I would not construct the attack by trying random numbers and checking them for
whether they are a public key. I would s
> "Jari" == Jari Arkko writes:
>> What is it that you don't understand. I will be happy to explain
>> it to you.
Jari> Thanks. I read the details, but I'm missing the big
Jari> picture. I.e., some effort is required from the owner to
Jari> create an address. By repeating
fender correspond to an
> increase of time T*2^59 for the attacker.
>
> -Original Message-
> From: Jari Arkko [mailto:jari.ar...@piuha.net]
> Sent: Thursday, March 21, 2013 1:19 PM
> To: Christian Huitema; Hosnieh Rafiee
> Cc: Santosh Chokhani; ipv6@ietf.org; s...@ietf.org
In your previous mail you wrote:
> ... nor will have an opportunity to work on the code that is needed
> to try to break the RSA. I do not agree with what Christian posed
> about being able to easily break it mathematically in a few seconds
> and I will work on proving him wrong.
=> not only
Christian,
> SEC does not " increases costs equally for both attackers and defenders." An
> increase of time T for the defender correspond to an increase of time T*2^59
> for the attacker.
Right. I was speaking about the relative effort increase. For Sec = 0, I have
to do 1 unit of work, the
Jari Arkko 写于 2013-03-22 05:55:35:
>
> Hosnieh,
>
> > What is it that you don't understand. I will be happy to explain it to
you.
>
> Thanks. I read the details, but I'm missing the big picture. I.e.,
> some effort is required from the owner to create an address. By
> repeating that effort
1:19 PM
To: Christian Huitema; Hosnieh Rafiee
Cc: Santosh Chokhani; ipv6@ietf.org; s...@ietf.org; Ray Hunter
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas
Is there a conclusion of this thread? My read of it is that no amount of
tweaking how you calcula
Hosnieh,
> What is it that you don't understand. I will be happy to explain it to you.
Thanks. I read the details, but I'm missing the big picture. I.e., some effort
is required from the owner to create an address. By repeating that effort
(2^59)/2 times, someone else is likely to hit the same
stian Huitema; Hosnieh Rafiee
Cc: Santosh Chokhani; ipv6@ietf.org; s...@ietf.org; Ray Hunter
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas
Is there a conclusion of this thread? My read of it is that no amount of
tweaking how you calculate the IID hel
Is there a conclusion of this thread? My read of it is that no amount of
tweaking how you calculate the IID help the fact that in 59/62 bits you have a
limited space to search. The Sec scheme does help, but increases costs equally
for both attackers and defenders.
FWIW, I'm struggling to under
On Sun, 2013-03-17 at 16:46 +, Christian Huitema wrote:
> You may think that building public/private key pairs is a very
> expensive operation, but that is not true. The default algorithm for
> SSAS is RSA. Let's suppose you use 2048 bit long RSA keys. The key
> generation start by generating
alexandru.petre...@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik
> Nordmark'; 'Ray Hunter'; jeanmichel.com...@orange.com
> Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D
> action : draft-rafiee-6man-ssas
>
> The attack is *relatively
ay, March 17, 2013 4:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; s...@ietf.org
Cc: alexandru.petre...@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark';
'Ray Hunter'; jeanmichel.com...@orange.com
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-
; s...@ietf.org
Cc: alexandru.petre...@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark';
'Ray Hunter'; jeanmichel.com...@orange.com
Subject: RE: [saag] security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas
2048 bit RSA security is overstated. Cr
18 matches
Mail list logo
