Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 16 Mar 2013 14:27:20 +0100

Hello,

There was a discussion during my presentation about security considerations
regarding the use of my algorithm compared with those of the use of CGA. A
big mistake that is made when considering CGA security is that the sec value
plays an important role and that an attacker will need to do brute force
attacks against the IID in order to generate the same IID as is generated by
the use of CGA. In a CGA analysis paper they talk about a CGA security
vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the
exponential value and so they infer that by increasing the sec value used
with CGA it will be safer, but this Is not true. 

I, as an attacker, just to need to find your private key. That's it. This is
because you have already included the CGA parameters (public key, modifier,
and other required parameters) in the  packet that was sent and I will have
no problem in regenerating the CGA. My only problem will be in generating
the signature that can be verified by use of your public key. This means
that you just increased the complexity and time required for generating and
verifying the IID while with SSAS you can obtain the same security as when
using CGA because its security also depends on the Hash function that is
used to generate the key pair and signature. 

If you send the CGA parameters via a safe channel, like in establishing TLS
etc., then, in that case, CGA would be more secure than SSAS. But in
practice all the data is sent in the same packet without encryption. If a
secured channel would be used in the CGA process for security reasons
(sending CGA parameters), then the cost of using CGA would be much greater
than the cost of using SSAS.

Now the question is, Why not use a more cost efficient algorithm that afford
you with the same security level as when using CGA. 

I have also included the security group in this email so that they can also
give me any comments that they might have.

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sat, 16 Mar 2013 16:36:33 +0000

It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: [email-masked]; [email-masked]
Cc: Erik Nordmark; [email-masked]; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Hello,
There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true.
I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the  packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature.
If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS.

Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA.

I have also included the security group in this email so that they can also give me any comments that they might have.

Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 16 Mar 2013 18:59:29 +0100

Hi Christian,

> But can y toou explain why you believe that retrieving the private key
from the public key and a clear text/encrypted text pair is easier than
breaking a hash? 

Here we do not use any encryption and decryption and we just sign the
message using private key and verify the message using public key.

>Did you somehow crack RSA?

I do not say that it is easier to find the private key from the public key.
Because for both SSAS and CGA, public/private keys are used. I do say that
the SHAx steps used for CGA generation do not increase the complexity when
used against brute force attacks. This is because an attacker only needs the
private key and does not need to find the modifier that was used in the
generation of the node's IID nor is there a need for checking the condition
of sec by 16 bits which should be equal to zero. In SSAS I just use the
public/private keys and the signature and nothing is encrypted/decrypted. In
CGA some extra SHAx steps are used in the generation of their IID along with
the signature. I say that these steps are not needed as long as you include
and send all parameters, used in the SHAx process, in the packet for
verification purposes. Some people feel that CGA  is secure enough when
those steps are used. Now what I want to point out here is that the CGA
security level is only dependent on the algorithm used for key pair and
signature generation and that those extra steps do nothing enhance the
security side of things. The algorithms used can be RSA or ECC or whatever,
and as such the situation will be the same as it is for SSAS. I just removed
the complexity from the use of CGA in order to enable a more practical and
faster generation and verification process.

So the question isn't how to break the encrypted text but how to break the
signature. In other word,  to find the same public key as used by the
generator node or how to break the RSA or ECC. Based on my knowledge of hash
algorithms, as I mentioned in my prior sentence, this will depend on the
strength of the RSA or whatever other  algorithm is used to generate these
keys and sign the message. If you or anyone else thinks otherwise, please
contribute to this discussion and share your opinions. I am just comparing
the security aspects of SSAS, the time efficient algorithm, to those of CGA.

Thank you,

Hosnieh

From: Christian Huitema [mailto:[email-masked]] 
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; [email-masked]; [email-masked]
Cc: Erik Nordmark; [email-masked]; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

It is very clear that if the attacker finds the private key, the size of the
hash does not matter. But can you explain why you believe that retrieving
the private key from the public key and a clear text/encrypted text pair is
easier than breaking a hash? Did you somehow crack RSA?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: [email-masked]; [email-masked]
Cc: Erik Nordmark; [email-masked]; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sat, 16 Mar 2013 18:30:05 +0000

As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible.

The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC.

From: Hosnieh Rafiee [mailto:[email-masked]]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; Michael Richardson; [email-masked]; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Hi Christian,

> But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash?

Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key.

>Did you somehow crack RSA?

I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA  is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process.

So the question isn't how to break the encrypted text but how to break the signature. In other word,  to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other  algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA.

Thank you,
Hosnieh

From: Christian Huitema [mailto:[email-masked]]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Erik Nordmark; [email-masked]<mailto:[email-masked]>; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Erik Nordmark; [email-masked]<mailto:[email-masked]>; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Hello,

Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sat, 16 Mar 2013 21:44:36 +0100

>The "SEC" part of CGA is meant to protect against a different attack, one
in which the attacker has not cracked the private key. Instead, the attacker
uses a public/private key pair of his own >choosing, and arrange for the
hash of that key to match the CGA address of the target. This "only"
requires O(2**(59+SEC*16)) operations, which even with large values of SEC
is still far less than >what is required to crack RSA or ECC.

So according to what I understand from what you wrote, the sec value makes
the for an easier attack against CGA as the attacker only needs to find the
same value generated by his own modifier and other parameters and matches
this to the IID of the node. Now the question again is, if this gives an
attacker a leg up in doing his brute force attacks why do we need to add
those steps to CGA. This was why I used the direct public key as a part of
IP address.

Thanks again Christian.

Hosnieh

From: Christian Huitema [mailto:[email-masked]] 
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; Michael
Richardson; [email-masked]; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

As you say, the attack that you mention depends on the strength of RSA or
ECC. In fact, pretty much all of public key cryptography depends on that
strength. It is generally assumed that cracking a long enough RSA or ECC key
is nearly impossible. 

The "SEC" part of CGA is meant to protect against a different attack, one in
which the attacker has not cracked the private key. Instead, the attacker
uses a public/private key pair of his own choosing, and arrange for the hash
of that key to match the CGA address of the target. This "only" requires
O(2**(59+SEC*16)) operations, which even with large values of SEC is still
far less than what is required to crack RSA or ECC.

From: Hosnieh Rafiee [mailto:[email-masked]] 
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; Michael
Richardson; [email-masked]; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

Hi Christian,

Thank you,

Hosnieh

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sun, 17 Mar 2013 08:14:07 +0000

The attack is *relatively* easier. It is not "easy." It is much harder to crack RSA than to find a matching hash. Cracking a 2048 bits RSA key probably requires on the order of 2^1024 trials, and that will take you something like "forever." Cracking the hash requires only something on the order of 2^91 trials with SEC=2. That's obviously much less, but that's still a very large number. The exhausting search will take you many years, i.e. much more than the valid lifetime of the address.

From: Hosnieh Rafiee [mailto:[email-masked]]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 'Michael Richardson'; [email-masked]; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

>The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC.

So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address.

Thanks again Christian.
Hosnieh

Cc: 'Erik Nordmark'; [email-masked]<mailto:[email-masked]>; 'Ray Hunter'; Michael Richardson; [email-masked]<mailto:[email-masked]>; Roque Gagliano (rogaglia)

From: Hosnieh Rafiee [mailto:[email-masked]]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: 'Erik Nordmark'; [email-masked]<mailto:[email-masked]>; 'Ray Hunter'; Michael Richardson; [email-masked]<mailto:[email-masked]>; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 17 Mar 2013 17:22:23 +0100

Thanks Christian. You answered my question. This is what I wanted to know
about security when directly using keys or using in the way CGA does. Both
are difficult but the CGA way is relatively easier than cracking the RSA
keys.

Hosnieh

From: Christian Huitema [mailto:[email-masked]] 
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh Rafiee; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 'Michael
Richardson'; [email-masked]; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

The attack is *relatively* easier. It is not "easy." It is much harder to
crack RSA than to find a matching hash. Cracking a 2048 bits RSA key
probably requires on the order of 2^1024 trials, and that will take you
something like "forever." Cracking the hash requires only something on the
order of 2^91 trials with SEC=2. That's obviously much less, but that's
still a very large number. The exhausting search will take you many years,
i.e. much more than the valid lifetime of the address.

From: Hosnieh Rafiee [mailto:[email-masked]] 
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 'Michael
Richardson'; [email-masked]; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

Thanks again Christian.

Hosnieh

Hi Christian,

Thank you,

Hosnieh

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sun, 17 Mar 2013 16:46:26 +0000

On the other hand, cracking SSAS is *much* easier than cracking RSA, or even cracking CGA.

SSAS builds the 64 bit identifier as follow:

*         Pick a random 16 bit number;

*         Use that number as an index in the bit array representing the public key;

*         Extract the 48 bits following the index;

*         Concatenate the random 16 bit number and the 48 bits of the key to build a 64 bit interface ID;

*         Prove possession of the public/private key pair when using the resulting IPv6 address.

An attacker can obviously break that scheme in about 2**48 trials, by generating a set of random  public/private key pairs. For each generated key, there is 2**-48 probability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public key in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They can then select that key pair, and spoof the IPv6 SSAS address at will.

2**48 is much less than the 2**59 figure for the CGA/Sec=0 algorithm, let alone using SEC=1 or SEC=2.

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 a set of 1024 bit long prime numbers. In theory, we need about 2*25 such numbers. Add a margin to be on the safe side. These numbers can be generated once, they don't have to be regenerated for every SSAS key being tried.

An RSA key is the product of two such numbers. 2*25 numbers allow you to compute 2**48 products, i.e. 2**48 candidate public keys. Computing a long integer product does take a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint will be very quick!

Sent: Sunday, March 17, 2013 9:22 AM

Thanks Christian. You answered my question. This is what I wanted to know about security when directly using keys or using in the way CGA does. Both are difficult but the CGA way is relatively easier than cracking the RSA keys.

Hosnieh

Cc: 'Erik Nordmark'; [email-masked]<mailto:[email-masked]>; 'Ray Hunter'; 'Michael Richardson'; [email-masked]<mailto:[email-masked]>; 'Roque Gagliano (rogaglia)'

Cc: 'Erik Nordmark'; [email-masked]<mailto:[email-masked]>; 'Ray Hunter'; 'Michael Richardson'; [email-masked]<mailto:[email-masked]>; 'Roque Gagliano (rogaglia)'

Thanks again Christian.
Hosnieh

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Sun, 17 Mar 2013 19:47:02 +0100

Thanks again for your response. I have some questions:

-          Choosing a random part of the public key does not help to
increase the probability of matching the public key to the IID?

if I am to improve this section and by saying we need to generate two, one
byte random numbers such that the second byte must not be higher than the
size of public key minus 6. 

-          How many days does it take to break SSAS?  I ask this because for
privacy I consider changing the key pairs and creating a new IP address in a
certain time frame.

Hosnieh

Sent: Sunday, March 17, 2013 5:46 PM

On the other hand, cracking SSAS is *much* easier than cracking RSA, or even
cracking CGA.

.         Pick a random 16 bit number;

.         Use that number as an index in the bit array representing the
public key;

.         Extract the 48 bits following the index;

.         Concatenate the random 16 bit number and the 48 bits of the key to
build a 64 bit interface ID;

.         Prove possession of the public/private key pair when using the
resulting IPv6 address.

An attacker can obviously break that scheme in about 2**48 trials, by
generating a set of random  public/private key pairs. For each generated
key, there is 2**-48 probability that the indexed bits match the 48 bit
thumbprint. In about 2**48 trials, the attacker will get a public key in
which the 48 bits happen to match the 48 bit thumbprint in the IPv6 address.
They can then select that key pair, and spoof the IPv6 SSAS address at will.

2**48 is much less than the 2**59 figure for the CGA/Sec=0 algorithm, let
alone using SEC=1 or SEC=2.

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 a set of 1024 bit long prime numbers. In theory, we need about
2*25 such numbers. Add a margin to be on the safe side. These numbers can be
generated once, they don't have to be regenerated for every SSAS key being
tried. 

An RSA key is the product of two such numbers. 2*25 numbers allow you to
compute 2**48 products, i.e. 2**48 candidate public keys. Computing a long
integer product does take a few computations, but not much more than
computing a SHA hash. The search for a key that match the footprint will be
very quick!

Hosnieh

Thanks again Christian.

Hosnieh

Hi Christian,

Thank you,

Hosnieh

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Sun, 17 Mar 2013 19:33:53 +0000

I don't think the index helps much. I suspect that SSAS could be broken in minutes if someone did a parallel implementation on a GPU. Maybe seconds.

Frankly, I believe that you have fallen in the trap of "inventing your own crypto." Most of these inventions turn out to have flaws, and won't pass a serious review. I would advise that you withdraw that specific proposal.

Sent: Sunday, March 17, 2013 11:47 AM

-          Choosing a random part of the public key does not help to increase the probability of matching the public key to the IID?

if I am to improve this section and by saying we need to generate two, one byte random numbers such that the second byte must not be higher than the size of public key minus 6.

-          How many days does it take to break SSAS?  I ask this because for privacy I consider changing the key pairs and creating a new IP address in a certain time frame.

Hosnieh

Hosnieh

Thanks again Christian.
Hosnieh

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: Francis Dupont <[email-masked]>
Date: Sun, 17 Mar 2013 23:31:03 +0100

I seconds Christian's argument: CGA was carefully designed to offer
a security of the ownership property higher than you can get from
a direct use of the interface ID. Of course this has a cost in CGA
generation time (but not verification) at higher SEC values.

Now about 48 bits of a RSA public key I am not a cryptographer nor
believe this particular problem was analyzed but obviously the upper
bound is 2**48 attempts with changing one of the two private primes
and even checking primeness after differential multiply, i.e., a
simple addition. I am afraid Christian is right and an attack is
feasible in a delay shorter than usage duration (i.e., "weak" in
the military crypto definition of this term).

About RSA, signing is encryption of the message digest with a
prefix so it is the same thing to break private key encryption
or signing.

About ECC, ECDSA has the interesting property than verifying is
slower than signing. This comes from DSA itself, and ECDSA is
as far as I know the only standard way to sign with ECC.

Regards

[email-masked]

PS: of course I supports Christian's last advice (but you already
know that :-).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 17 Mar 2013 23:46:46 +0100

>  increase the probability of matching the public key to the IID?

=> IMHO the main good effect of this is that it makes a dictionary
of matching public key candidates not attractive... But this is
not enough to make the problem hard to solve.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2013 01:07:07 +0100

In your previous mail you wrote:

>  I don't think the index helps much. I suspect that SSAS could be broken in
>  minutes if someone did a parallel implementation on a GPU. Maybe seconds.

=> you peak 2 primes for a standard RSA public key. You fix one and
you divide the modulus to get an idea of the needed value for the
second to match the 48 bits, and an increment for the bits to match
position. Now you scan to get a prime which will give a matching
modulus, using addition for computing the next modulus.
The Hadamard-De la Vallee Poussin theorem (known in English as
the prime number theorem says the distribution is n/ln(n),
so as bc -l returns 710 for ln(2**1024) only at most 710 additions
(which are as complex as carry propagation, so count for nothing)
and primality checks are needed. I don't have the number for
primality check speed but my i5 laptop checks 1000 times a 1024
bit prime (which is the worst case) in 7 seconds in a shell script.

Regards

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 18 Mar 2013 01:40:46 +0100

Thanks Christian,

Here is what I propose. I have an implementation of SSAS and I will try to
break it to see how long it will take. (I will also share the code with
others so  that more people can try to break it.)  Based on the mathematical
calculations (of finding the expected value) the probability of it being
broken in one month is very low. Since we also want to use this for the
integration of privacy, then this is secure enough. But perhaps with my
implementation of the attacks against  SSAS I can learn the what happens in
realtime as opposed to mathematical theory. I have my doubts about what you
said about being able to break it in seconds. I am sorry but I feel that
what you said is really unrealistic. If you really are able to implement
something that does this, then you  probably would be able to break CGA in
seconds also. 

About the modifier that I have, I will also check to determine whether using
makes breaking it easier or harder. If it is easier. then I will use the
entire 64 bits of the public key (set bit u and g) and use the fixed part of
the public key. 

I am not trying to create a new hash algorithm but only make improvements to
my algorithm.

Francis: SSAS also provides proof of IP address ownership as does CGA.  The
question here is not that but is on the security considerations that are
based on my calculations with regard to the probability of being able to
break it. I believe that what Christian says is not true, but I will have to
try it to prove him wrong. About other algorithms, CGA can use them as well
so you cannot compare the computational times based on the use of those
algorithms.

Hosnieh

Sent: Sunday, March 17, 2013 8:34 PM

Frankly, I believe that you have fallen in the trap of "inventing your own
crypto." Most of these inventions turn out to have flaws, and won't pass a
serious review. I would advise that you withdraw that specific proposal.

Hosnieh

 

Hosnieh

Thanks again Christian.

Hosnieh

Hi Christian,

Thank you,

Hosnieh

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Mon, 18 Mar 2013 01:43:47 +0000

Hosnieh, making your own breaking code is a good exercise and you will certainly learn a lot. However, you will only obtain a "maximum" estimate of the breaking time.  For example, if you could break the algorithm in 1000 hours, that mean opponents will be able to break it in 1000 hours *or less.*Often, that will be much less. Key points in robustness are, for example:

1)      How many bits? To give an example, 56 bits DES keys can be broken in seconds using special purpose equipment. AES uses 128 or 256 bit keys, especially for that purpose. Generally, we want to increase the number of bits as Moore's law progresses.

2)      Can it be parallelized? If it can, that means an attacker can solve it much faster using more computers. Think for example of a GPU with the equivalent of 1000 parallel processors, or a botnet with 1M machines, or even worse a botnet with 1M machines each with a GPU.

3)      Can part of the solutions be computed in advance? The famous examples are the "rainbow table" that could be used to crack hashes of passwords, if these hashes were not protected by some "salt."

SSAS is weak on all these counts. Part of the solution can be computed in advance: 2^25 bit prime numbers about 1024 bit long occupy 2^32 octets, i.e. a gigabyte. That can be stored, copied and distributed easily. The breaking algorithm can be parallelized trivially: have millions of nodes in the botnet each pick random seeds, and explore different parts of the solution. The number of bits is fixed to 62 bits at most, which means that as Moore's law progresses SSAS is bound to get ever weaker, with no space to grow.

The SEC scheme in CGA was specifically designed to address these weaknesses. Including the prefix in the hash prevents the use of "rainbow tables." The hash only uses 59 bits because some bits are reserved for the SEC field, but the SEC fields allows for robust extensions of the hash length as Moore's law progresses. This allows node to trade off robustness versus address generation time. CGA implementers concerned with parallelized attacks have the choice of making the hash virtually longer by using larger SEC values - 20 extra bits will mitigate the 1M botnet.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hosnieh Rafiee
Sent: Sunday, March 17, 2013 5:41 PM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; [email-masked]
Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Thanks Christian,
Here is what I propose. I have an implementation of SSAS and I will try to break it to see how long it will take. (I will also share the code with others so  that more people can try to break it.)  Based on the mathematical calculations (of finding the expected value) the probability of it being broken in one month is very low. Since we also want to use this for the integration of privacy, then this is secure enough. But perhaps with my implementation of the attacks against  SSAS I can learn the what happens in realtime as opposed to mathematical theory. I have my doubts about what you said about being able to break it in seconds. I am sorry but I feel that what you said is really unrealistic. If you really are able to implement something that does this, then you  probably would be able to break CGA in seconds also.
About the modifier that I have, I will also check to determine whether using makes breaking it easier or harder. If it is easier. then I will use the entire 64 bits of the public key (set bit u and g) and use the fixed part of the public key.
I am not trying to create a new hash algorithm but only make improvements to  my algorithm.

Francis: SSAS also provides proof of IP address ownership as does CGA.  The question here is not that but is on the security considerations that are based on my calculations with regard to the probability of being able to break it. I believe that what Christian says is not true, but I will have to try it to prove him wrong. About other algorithms, CGA can use them as well so you cannot compare the computational times based on the use of those algorithms.

Hosnieh

Hosnieh

Hosnieh

Thanks again Christian.
Hosnieh

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 18 Mar 2013 02:51:18 +0100

I do not try it in a standard pc. We have a powerful giant super computer,
see here
http://www.hpi.uni-potsdam.de/forschung/future_soc_lab/lab/the_lab_and_its_r
esources.html?L=1 

Thanks,

Hosnieh

From: Christian Huitema [mailto:[email-masked]] 
Sent: Monday, March 18, 2013 2:44 AM
To: Hosnieh Rafiee; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; 'Roque Gagliano
(rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; [email-masked]
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

Hosnieh, making your own breaking code is a good exercise and you will
certainly learn a lot. However, you will only obtain a "maximum" estimate of
the breaking time.  For example, if you could break the algorithm in 1000
hours, that mean opponents will be able to break it in 1000 hours *or
less.*Often, that will be much less. Key points in robustness are, for
example:

1)      How many bits? To give an example, 56 bits DES keys can be broken in
seconds using special purpose equipment. AES uses 128 or 256 bit keys,
especially for that purpose. Generally, we want to increase the number of
bits as Moore's law progresses.

2)      Can it be parallelized? If it can, that means an attacker can solve
it much faster using more computers. Think for example of a GPU with the
equivalent of 1000 parallel processors, or a botnet with 1M machines, or
even worse a botnet with 1M machines each with a GPU.

3)      Can part of the solutions be computed in advance? The famous
examples are the "rainbow table" that could be used to crack hashes of
passwords, if these hashes were not protected by some "salt."

SSAS is weak on all these counts. Part of the solution can be computed in
advance: 2^25 bit prime numbers about 1024 bit long occupy 2^32 octets, i.e.
a gigabyte. That can be stored, copied and distributed easily. The breaking
algorithm can be parallelized trivially: have millions of nodes in the
botnet each pick random seeds, and explore different parts of the solution.
The number of bits is fixed to 62 bits at most, which means that as Moore's
law progresses SSAS is bound to get ever weaker, with no space to grow.

The SEC scheme in CGA was specifically designed to address these weaknesses.
Including the prefix in the hash prevents the use of "rainbow tables." The
hash only uses 59 bits because some bits are reserved for the SEC field, but
the SEC fields allows for robust extensions of the hash length as Moore's
law progresses. This allows node to trade off robustness versus address
generation time. CGA implementers concerned with parallelized attacks have
the choice of making the hash virtually longer by using larger SEC values -
20 extra bits will mitigate the 1M botnet. 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hosnieh Rafiee
Sent: Sunday, March 17, 2013 5:41 PM
To: Christian Huitema; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; 'Roque Gagliano
(rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; [email-masked]
Subject: RE: security consideration of CGA and SSAS - Ii-D action :
draft-rafiee-6man-ssas

Thanks Christian,

Hosnieh

Hosnieh

 

Hosnieh

Thanks again Christian.

Hosnieh

Hi Christian,

Thank you,

Hosnieh

Hello,

Thank you,

Hosnieh

---

From: Christian Huitema <[email-masked]>
Date: Mon, 18 Mar 2013 02:03:46 +0000

Santosh, I suppose we have to use more than 2048 bits for RSA then... But that's not really the point of the debate.

CGA is an algorithm specified for IPv6 "secure neighbor discovery" and is specified in RFC 3972. CGA works by associating an IPv6 address with a public key. The public key is hashed with the network prefix (first 64 bits of IPv6 address) and 59 bits of the hash are copied to the host identifier part of the IPv6 address. In the most basic implementation, senders prove ownership of the address by demonstrating possession of a public/private key pair, and receiver verify also that the specified 59 bits of the hash match what is in the address.

Of course, 59 bits is a rather small number, and matching only 59 bits instead of 160 seriously weakens the strength of the algorithm. The CGA spec includes a "hash augmentation" mechanism, the "SEC" fields, which specifies an additional constraint on the content of the hash, namely that the hash begins by a set number of zeroes - 16 times the number in the SEC field. That mechanism requires that the host generating a secure address spends some time finding the right hash.

Hosnieh proposes to replace that mechanism by simply copying in the IPv6 address a number of bits from the public key - 48 in the original proposal.

From: Santosh Chokhani [mailto:[email-masked]]
Sent: Sunday, March 17, 2013 6:36 PM
To: Christian Huitema; Hosnieh Rafiee; [email-masked]; [email-masked]
Cc: [email-masked]; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; [email-masked]
Subject: RE: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

2048 bit RSA security is overstated.  Cracking it requires on the order of 2^112 operations.  You should look at NIST SP 800-57 Part 2, Table 2 Section 5.6.1.

>From the description you provide on hashing, finding a second hash is a second pre-image attack and for SHA-1 the security strength is 160 bits, i.e., you need on the order of 2^160 operations.

I do not know what hash function you are describing for the function you mention and how you derived its security strength.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Christian Huitema
Sent: Sunday, March 17, 2013 4:14 AM
To: Hosnieh Rafiee; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; [email-masked]<mailto:[email-masked]>
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Thanks again Christian.
Hosnieh

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Mar 2013 11:19:41 +0100

>  entire 64 bits of the public key (set bit u and g) and use the fixed part of

=> I don't believe 64 vs 48 bits will change a lot for a RSA public key.

>  so you cannot compare the computational times based on the use of those

=> I fully disagree with your security considerations. My math shows
to build a matching RSA public key takes a similar time than to
build a new RSA key pair. Note it won't be enough to go through
a hash function and to take benefit of pre-image resistance because
you doesn't have enough bit in the interface ID. My conclusion is
you have to reinvent CGAs to get similar/equivalent security properties.

Regards

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 17 Mar 2013 21:36:25 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Huitema

Thanks again Christian.
Hosnieh

Hi Christian,

Thank you,
Hosnieh

Hello,

Thank you,
Hosnieh

---

From: [email-masked]
Date: Tue, 19 Mar 2013 11:49:29 +0800

[email-masked] 写于 2013-03-18 09:36:25:

> 2048 bit RSA security is overstated.  Cracking it requires on the 
> order of 2^112 operations.  You should look at NIST SP 800-57 Part 
> 2, Table 2 Section 5.6.1.

It is in Part 1:
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf 

> From the description you provide on hashing, finding a second hash 
> is a second pre-image attack and for SHA-1 the security strength is 
> 160 bits, i.e., you need on the order of 2^160 operations.
> 
> I do not know what hash function you are describing for the function
> you mention and how you derived its security strength.
> 
> Cc: [email-masked]; 'Roque Gagliano (rogaglia)'; 'Erik
> Nordmark'; 'Ray Hunter'; [email-masked]
> The attack is *relatively* easier. It is not “easy.” It is much 
> harder to crack RSA than to find a matching hash. Cracking a 2048 
> bits RSA key probably requires on the order of 2^1024 trials, and 
> that will take you something like “forever.” Cracking the hash 
> requires only something on the order of 2^91 trials with SEC=2. 
> That’s obviously much less, but that’s still a very large number. 
> The exhausting search will take you many years, i.e. much more than 
> the valid lifetime of the address.
> 
> Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 
> 'Michael Richardson'; [email-masked]; 'Roque Gagliano 
> (rogaglia)'
> >The “SEC” part of CGA is meant to protect against a different 
> attack, one in which the attacker has not cracked the private key. 
> Instead, the attacker uses a public/private key pair of his own 
> >choosing, and arrange for the hash of that key to match the CGA 
> address of the target. This “only” requires O(2**(59+SEC*16)) 
> operations, which even with large values of SEC is still far less 
> than >what is required to crack RSA or ECC.
> 
> So according to what I understand from what you wrote, the sec value
> makes the for an easier attack against CGA as the attacker only 
> needs to find the same value generated by his own modifier and other
> parameters and matches this to the IID of the node. Now the question
> again is, if this gives an attacker a leg up in doing his brute 
> force attacks why do we need to add those steps to CGA. This was why
> I used the direct public key as a part of IP address.
> 
> Thanks again Christian.
> Hosnieh
> 
> Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 
> Michael Richardson; [email-masked]; Roque Gagliano 
(rogaglia)
> As you say, the attack that you mention depends on the strength of 
> RSA or ECC. In fact, pretty much all of public key cryptography 
> depends on that strength. It is generally assumed that cracking a 
> long enough RSA or ECC key is nearly impossible. 
> 
> The “SEC” part of CGA is meant to protect against a different 
> attack, one in which the attacker has not cracked the private key. 
> Instead, the attacker uses a public/private key pair of his own 
> choosing, and arrange for the hash of that key to match the CGA 
> address of the target. This “only” requires O(2**(59+SEC*16)) 
> operations, which even with large values of SEC is still far less 
> than what is required to crack RSA or ECC.
> 
> Cc: 'Erik Nordmark'; [email-masked]; 'Ray Hunter'; 
> Michael Richardson; [email-masked]; Roque Gagliano 
(rogaglia)
> > But can y toou explain why you believe that retrieving the private
> key from the public key and a clear text/encrypted text pair is 
> easier than breaking a hash? 
> 
> Here we do not use any encryption and decryption and we just sign 
> the message using private key and verify the message using public key.
> 
> I do not say that it is easier to find the private key from the 
> public key. Because for both SSAS and CGA, public/private keys are 
> used. I do say that the SHAx steps used for CGA generation do not 
> increase the complexity when used against brute force attacks. This 
> is because an attacker only needs the private key and does not need 
> to find the modifier that was used in the generation of the node’s 
> IID nor is there a need for checking the condition of sec by 16 bits
> which should be equal to zero. In SSAS I just use the public/private
> keys and the signature and nothing is encrypted/decrypted. In CGA 
> some extra SHAx steps are used in the generation of their IID along 
> with the signature. I say that these steps are not needed as long as
> you include and send all parameters, used in the SHAx process, in 
> the packet for verification purposes. Some people feel that CGA  is 
> secure enough when those steps are used. Now what I want to point 
> out here is that the CGA security level is only dependent on the 
> algorithm used for key pair and signature generation and that those 
> extra steps do nothing enhance the security side of things. The 
> algorithms used can be RSA or ECC or whatever, and as such the 
> situation will be the same as it is for SSAS. I just removed the 
> complexity from the use of CGA in order to enable a more practical 
> and faster generation and verification process.
> 
> So the question isn’t how to break the encrypted text but how to 
> break the signature. In other word,  to find the same public key as 
> used by the generator node or how to break the RSA or ECC. Based on 
> my knowledge of hash algorithms, as I mentioned in my prior 
> sentence, this will depend on the strength of the RSA or whatever 
> other  algorithm is used to generate these keys and sign the 
> message. If you or anyone else thinks otherwise, please contribute 
> to this discussion and share your opinions. I am just comparing the 
> security aspects of SSAS, the time efficient algorithm, to those of CGA.
> 
> Thank you,
> Hosnieh
> 
> 
> It is very clear that if the attacker finds the private key, the 
> size of the hash does not matter. But can you explain why you 
> believe that retrieving the private key from the public key and a 
> clear text/encrypted text pair is easier than breaking a hash? Did 
> you somehow crack RSA?
> 
> There was a discussion during my presentation about security 
> considerations regarding the use of my algorithm compared with those
> of the use of CGA. A big mistake that is made when considering CGA 
> security is that the sec value plays an important role and that an 
> attacker will need to do brute force attacks against the IID in 
> order to generate the same IID as is generated by the use of CGA. In
> a CGA analysis paper they talk about a CGA security vaulue of pow 
> (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the 
> exponential value and so they infer that by increasing the sec value
> used with CGA it will be safer, but this Is not true. 
> I, as an attacker, just to need to find your private key. That’s it.
> This is because you have already included the CGA parameters (public
> key, modifier, and other required parameters) in the  packet that 
> was sent and I will have no problem in regenerating the CGA. My only
> problem will be in generating the signature that can be verified by 
> use of your public key. This means that you just increased the 
> complexity and time required for generating and verifying the IID 
> while with SSAS you can obtain the same security as when using CGA 
> because its security also depends on the Hash function that is used 
> to generate the key pair and signature. 
> If you send the CGA parameters via a safe channel, like in 
> establishing TLS etc., then, in that case, CGA would be more secure 
> than SSAS. But in practice all the data is sent in the same packet 
> without encryption. If a secured channel would be used in the CGA 
> process for security reasons (sending CGA parameters), then the cost
> of using CGA would be much greater than the cost of using SSAS.
> 
> Now the question is, Why not use a more cost efficient algorithm 
> that afford you with the same security level as when using CGA. 
> 
> I have also included the security group in this email so that they 
> can also give me any comments that they might have.
> 
> Thank you,
> 
Hosnieh--------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Mar 2013 16:05:53 -0400

On Sun, 2013-03-17 at 16:46 +0000, 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 a set of 1024 bit long prime numbers. In
> theory, we need about 2*25 such numbers. Add a margin to be on the safe
> side. These numbers can be generated once, they don't have to be
> regenerated for every SSAS key being tried.

Hold on.  If I'm an attacker, who says my "primes" even have to be
prime?

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2013 22:19:20 +0200

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 understand the draft. But I couldn't make it to the meeting.

Jari

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 21 Mar 2013 22:29:43 +0100

Hi Jeri,
What is it that you don't understand. I will be happy to explain it to you.
There has been no resolution to the topic of the thread... I have been
traveling and will be traveling all of next week so I have not had 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.
Hosnieh

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, March 21, 2013 9:19 PM
To: Christian Huitema; Hosnieh Rafiee
Cc: Santosh Chokhani; [email-masked]; [email-masked]; 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 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 understand the draft. But I couldn't make it to the
meeting.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Mar 2013 23:55:35 +0200

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 key with a key pair that he or she controls, and an attack can be launched. What changes from RFC 3972 to your draft in this high-level analysis?

> There has been no resolution to the topic of the thread… 

Ok. Well that clarifies at least the state of the discussion. Thanks.

Jari

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Mar 2013 23:46:02 +0000

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.

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, March 21, 2013 1:19 PM
To: Christian Huitema; Hosnieh Rafiee
Cc: Santosh Chokhani; [email-masked]; [email-masked]; Ray Hunter
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas

Jari

---

From: [email-masked]
Date: Fri, 22 Mar 2013 10:17:49 +0800

Jari Arkko <[email-masked]> 写于 2013-03-22 05:55:35:

> 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 
Should be less than (2^59)/2 which is an estimation for hash collision.
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.
For the CGA, 
    the probability of a second public key   is:2^{-29.5}*p 

The first probability should be quite quite bigger than the second. 

> the same key with a key pair that he or she controls, and an attack 
> can be launched. What changes from RFC 3972 to your draft in this 
> high-level analysis?
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Mar 2013 08:38:54 +0200

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 attacker 2^59 units of work. For Sec = 1, I have to do 2^16 units of work, the attacker 2^16 * 2^59 units of work. The difference in the amount of time I and the attacker have to do is always 2^59, but with Sec we can change how much work that is.

Jari

---

From: Francis Dupont <[email-masked]>
Date: Fri, 22 Mar 2013 09:56:47 +0100

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 I agree with Christian Huitema but I showed a proof that
in the RSA case the proposal can be broken in a time frame similar
to the key pair generation one and independently of the number of bits,
i.e., 48 as in the proposal or up to 64 which is the maximum from
the Interface ID.
So my conclusion is for the security an attempt to provide the same
level than CGAs should only reinvent CGAs.
About privacy I have the same concerns about the proposal than about
RFC 3041/4941, i.e., to change the IID doesn't help when the assigned
prefix is kept.

Regards

---

From: Ray Hunter <[email-masked]>
Date: Fri, 22 Mar 2013 10:01:33 +0100

agreed.

FWIW I suggested to Hosnieh earlier (in a private mail) to support
multiple alternative authentication mechanisms, and to make this
flexible for the future.

This draft is effectively discussing tuning an authentication protocol
to reduce the amount of work done by the defender (to make it faster
than CGA) whilst keeping the amount of work the attacker has to do high
enough to avoid common attacks.

We can argue all we like about the current balance of power as of today,
but that's not the main issue.

IMHO Over the course of years that this type of protocol is in
operation, the work has to increase for both defender and attacker (due
to Moore's law) to keep the "amount of effort to break" constant. CGA
allows this. The current draft does not.
> Jari Arkko <mailto:[email-masked]>
> 22 March 2013 07:38
> Christian,
>
>
> Right. I was speaking about the relative effort increase. For Sec = 0,
> I have to do 1 unit of work, the attacker 2^59 units of work. For Sec
> = 1, I have to do 2^16 units of work, the attacker 2^16 * 2^59 units
> of work. The difference in the amount of time I and the attacker have
> to do is always 2^59, but with Sec we can change how much work that is.
>
> Jari
>
> Christian Huitema <mailto:[email-masked]>
> 22 March 2013 00:46
> 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.
>
> 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.
>
> Jari Arkko <mailto:[email-masked]>
> 21 March 2013 21:19
> 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.
>
> Christian Huitema <mailto:[email-masked]>
> 18 March 2013 03:03
>
> Santosh, I suppose we have to use more than 2048 bits for RSA then…
> But that’s not really the point of the debate.
>
> CGA is an algorithm specified for IPv6 “secure neighbor discovery” and
> is specified in RFC 3972. CGA works by associating an IPv6 address
> with a public key. The public key is hashed with the network prefix
> (first 64 bits of IPv6 address) and 59 bits of the hash are copied to
> the host identifier part of the IPv6 address. In the most basic
> implementation, senders prove ownership of the address by
> demonstrating possession of a public/private key pair, and receiver
> verify also that the specified 59 bits of the hash match what is in
> the address.
>
> Of course, 59 bits is a rather small number, and matching only 59 bits
> instead of 160 seriously weakens the strength of the algorithm. The
> CGA spec includes a “hash augmentation” mechanism, the “SEC” fields,
> which specifies an additional constraint on the content of the hash,
> namely that the hash begins by a set number of zeroes – 16 times the
> number in the SEC field. That mechanism requires that the host
> generating a secure address spends some time finding the right hash.
>
> Hosnieh proposes to replace that mechanism by simply copying in the
> IPv6 address a number of bits from the public key – 48 in the original
> proposal.
>
> *From:* Santosh Chokhani [mailto:[email-masked]]
> *Sent:* Sunday, March 17, 2013 6:36 PM
> *To:* Christian Huitema; Hosnieh Rafiee; [email-masked]; [email-masked]
> *Cc:* [email-masked]; 'Roque Gagliano (rogaglia)'; 'Erik
> *Subject:* RE: [saag] security consideration of CGA and SSAS - Ii-D
> action : draft-rafiee-6man-ssas
>
> 2048 bit RSA security is overstated. Cracking it requires on the order
> of 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2
> Section 5.6.1.
>
> From the description you provide on hashing, finding a second hash is
> a second pre-image attack and for SHA-1 the security strength is 160
> bits, i.e., you need on the order of 2^160 operations.
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Christian Huitema
> *Sent:* Sunday, March 17, 2013 4:14 AM
> *To:* Hosnieh Rafiee; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked]
> <mailto:[email-masked]>; 'Roque Gagliano (rogaglia)';
> 'Erik Nordmark'; 'Ray Hunter'; [email-masked]
> <mailto:[email-masked]>
> *Subject:* Re: [saag] security consideration of CGA and SSAS - Ii-D
> action : draft-rafiee-6man-ssas
>
> The attack is **relatively** easier. It is not “easy.” It is much
> harder to crack RSA than to find a matching hash. Cracking a 2048 bits
> RSA key probably requires on the order of 2^1024 trials, and that will
> take you something like “forever.” Cracking the hash requires only
> something on the order of 2^91 trials with SEC=2. That’s obviously
> much less, but that’s still a very large number. The exhausting search
> will take you many years, i.e. much more than the valid lifetime of
> the address.
>
> *From:* Hosnieh Rafiee [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 1:45 PM
> *To:* Christian Huitema; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; 'Michael
> Richardson'; [email-masked]
> <mailto:[email-masked]>; 'Roque Gagliano (rogaglia)'
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> >The “SEC” part of CGA is meant to protect against a different attack,
> one in which the attacker has not cracked the private key. Instead,
> the attacker uses a public/private key pair of his own >choosing, and
> arrange for the hash of that key to match the CGA address of the
> target. This “only” requires O(2**(59+SEC*16)) operations, which even
> with large values of SEC is still far less than >what is required to
> crack RSA or ECC.
>
> makes the for an easier attack against CGA as the attacker only needs
> to find the same value generated by his own modifier and other
> again is, if this gives an attacker a leg up in doing his brute force
> attacks why do we need to add those steps to CGA. This was why I used
> the direct public key as a part of IP address.
>
> Thanks again Christian.
>
> Hosnieh
>
> *From:*Christian Huitema [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 7:30 PM
> *To:* Hosnieh Rafiee; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; Michael
> Richardson; [email-masked]
> <mailto:[email-masked]>; Roque Gagliano (rogaglia)
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> As you say, the attack that you mention depends on the strength of RSA
> or ECC. In fact, pretty much all of public key cryptography depends on
> that strength. It is generally assumed that cracking a long enough RSA
> or ECC key is nearly impossible.
>
> The “SEC” part of CGA is meant to protect against a different attack,
> one in which the attacker has not cracked the private key. Instead,
> the attacker uses a public/private key pair of his own choosing, and
> arrange for the hash of that key to match the CGA address of the
> target. This “only” requires O(2**(59+SEC*16)) operations, which even
> with large values of SEC is still far less than what is required to
> crack RSA or ECC.
>
> *From:* Hosnieh Rafiee [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 10:59 AM
> *To:* Christian Huitema; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; Michael
> Richardson; [email-masked]
> <mailto:[email-masked]>; Roque Gagliano (rogaglia)
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> Hi Christian,
>
> key from the public key and a clear text/encrypted text pair is easier
> than breaking a hash?
>
> I do not say that it is easier to find the private key from the public
> key. Because for both SSAS and CGA, public/private keys are used. I do
> say that the SHAx steps used for CGA generation do not increase the
> complexity when used against brute force attacks. This is because an
> attacker only needs the private key and does not need to find the
> modifier that was used in the generation of the node’s IID nor is
> there a need for checking the condition of sec by 16 bits which should
> be equal to zero. In SSAS I just use the public/private keys and the
> signature and nothing is encrypted/decrypted. In CGA some extra SHAx
> steps are used in the generation of their IID along with the
> signature. I say that these steps are not needed as long as you
> include and send all parameters, used in the SHAx process, in the
> packet for verification purposes. Some people feel that CGA is secure
> enough when those steps are used. Now what I want to point out here is
> that the CGA security level is *only* dependent on the algorithm used
> for key pair and signature generation and that those extra steps do
> nothing enhance the security side of things. The algorithms used can
> be RSA or ECC or whatever, and as such the situation will be the same
> as it is for SSAS. I just removed the complexity from the use of CGA
> in order to enable a more practical and faster generation and
> verification process.
>
> So the question isn’t how to break the encrypted text but how to break
> the signature. In other word, to find the same public key as used by
> the generator node or how to break the RSA or ECC. Based on my
> knowledge of hash algorithms, as I mentioned in my prior sentence,
> this will depend on the strength of the RSA or whatever other
> algorithm is used to generate these keys and sign the message. If you
> or anyone else thinks otherwise, please contribute to this discussion
> and share your opinions. I am just comparing the security aspects of
> SSAS, the time efficient algorithm, to those of CGA.
>
> Thank you,
>
> Hosnieh
>
> *From:*Christian Huitema [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 5:37 PM
> *To:* Hosnieh Rafiee; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* Erik Nordmark; [email-masked]
> <mailto:[email-masked]>; Ray Hunter
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> It is very clear that if the attacker finds the private key, the size
> of the hash does not matter. But can you explain why you believe that
> retrieving the private key from the public key and a clear
> text/encrypted text pair is easier than breaking a hash? Did you
> somehow crack RSA?
>
> *From:* [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Hosnieh Rafiee
> *Sent:* Saturday, March 16, 2013 6:27 AM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Cc:* Erik Nordmark; [email-masked]
> <mailto:[email-masked]>; Ray Hunter
> *Subject:* security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> Hello,
>
> attacker will need to do brute force attacks against the IID in order
> to generate the same IID as is generated by the use of CGA. In a CGA
> analysis paper they talk about a CGA security vaulue of pow (2, sec*16
> * 59) where 2 is the base and sec*16 * 59 is the exponential value and
> so they infer that by increasing the sec value used with CGA it will
> be safer, but this Is not true.
>
> key, modifier, and other required parameters) in the packet that was
> sent and I will have no problem in regenerating the CGA. My only
> because its security also depends on the Hash function that is used to
> generate the key pair and signature.
>
> **
> *Now the question is, Why not use a more cost efficient algorithm that
> afford you with the same security level as when using CGA. *
>
> I have also included the security group in this email so that they can
> also give me any comments that they might have.
>
> Thank you,
>
> Hosnieh
>
> Santosh Chokhani <mailto:[email-masked]>
> 18 March 2013 02:36
>
> 2048 bit RSA security is overstated. Cracking it requires on the order
> of 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2
> Section 5.6.1.
>
> From the description you provide on hashing, finding a second hash is
> a second pre-image attack and for SHA-1 the security strength is 160
> bits, i.e., you need on the order of 2^160 operations.
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of *Christian Huitema
> *Sent:* Sunday, March 17, 2013 4:14 AM
> *To:* Hosnieh Rafiee; [email-masked]; [email-masked]
> *Cc:* [email-masked]; 'Roque Gagliano (rogaglia)'; 'Erik
> *Subject:* Re: [saag] security consideration of CGA and SSAS - Ii-D
> action : draft-rafiee-6man-ssas
>
> The attack is **relatively** easier. It is not “easy.” It is much
> harder to crack RSA than to find a matching hash. Cracking a 2048 bits
> RSA key probably requires on the order of 2^1024 trials, and that will
> take you something like “forever.” Cracking the hash requires only
> something on the order of 2^91 trials with SEC=2. That’s obviously
> much less, but that’s still a very large number. The exhausting search
> will take you many years, i.e. much more than the valid lifetime of
> the address.
>
> *From:* Hosnieh Rafiee [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 1:45 PM
> *To:* Christian Huitema; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; 'Michael
> Richardson'; [email-masked]
> <mailto:[email-masked]>; 'Roque Gagliano (rogaglia)'
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> >The “SEC” part of CGA is meant to protect against a different attack,
> one in which the attacker has not cracked the private key. Instead,
> the attacker uses a public/private key pair of his own >choosing, and
> arrange for the hash of that key to match the CGA address of the
> target. This “only” requires O(2**(59+SEC*16)) operations, which even
> with large values of SEC is still far less than >what is required to
> crack RSA or ECC.
>
> makes the for an easier attack against CGA as the attacker only needs
> to find the same value generated by his own modifier and other
> again is, if this gives an attacker a leg up in doing his brute force
> attacks why do we need to add those steps to CGA. This was why I used
> the direct public key as a part of IP address.
>
> Thanks again Christian.
>
> Hosnieh
>
> *From:*Christian Huitema [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 7:30 PM
> *To:* Hosnieh Rafiee; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; Michael
> Richardson; [email-masked]
> <mailto:[email-masked]>; Roque Gagliano (rogaglia)
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> As you say, the attack that you mention depends on the strength of RSA
> or ECC. In fact, pretty much all of public key cryptography depends on
> that strength. It is generally assumed that cracking a long enough RSA
> or ECC key is nearly impossible.
>
> The “SEC” part of CGA is meant to protect against a different attack,
> one in which the attacker has not cracked the private key. Instead,
> the attacker uses a public/private key pair of his own choosing, and
> arrange for the hash of that key to match the CGA address of the
> target. This “only” requires O(2**(59+SEC*16)) operations, which even
> with large values of SEC is still far less than what is required to
> crack RSA or ECC.
>
> *From:* Hosnieh Rafiee [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 10:59 AM
> *To:* Christian Huitema; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* 'Erik Nordmark'; [email-masked]
> <mailto:[email-masked]>; 'Ray Hunter'; Michael
> Richardson; [email-masked]
> <mailto:[email-masked]>; Roque Gagliano (rogaglia)
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> Hi Christian,
>
> key from the public key and a clear text/encrypted text pair is easier
> than breaking a hash?
>
> I do not say that it is easier to find the private key from the public
> key. Because for both SSAS and CGA, public/private keys are used. I do
> say that the SHAx steps used for CGA generation do not increase the
> complexity when used against brute force attacks. This is because an
> attacker only needs the private key and does not need to find the
> modifier that was used in the generation of the node’s IID nor is
> there a need for checking the condition of sec by 16 bits which should
> be equal to zero. In SSAS I just use the public/private keys and the
> signature and nothing is encrypted/decrypted. In CGA some extra SHAx
> steps are used in the generation of their IID along with the
> signature. I say that these steps are not needed as long as you
> include and send all parameters, used in the SHAx process, in the
> packet for verification purposes. Some people feel that CGA is secure
> enough when those steps are used. Now what I want to point out here is
> that the CGA security level is *only* dependent on the algorithm used
> for key pair and signature generation and that those extra steps do
> nothing enhance the security side of things. The algorithms used can
> be RSA or ECC or whatever, and as such the situation will be the same
> as it is for SSAS. I just removed the complexity from the use of CGA
> in order to enable a more practical and faster generation and
> verification process.
>
> So the question isn’t how to break the encrypted text but how to break
> the signature. In other word, to find the same public key as used by
> the generator node or how to break the RSA or ECC. Based on my
> knowledge of hash algorithms, as I mentioned in my prior sentence,
> this will depend on the strength of the RSA or whatever other
> algorithm is used to generate these keys and sign the message. If you
> or anyone else thinks otherwise, please contribute to this discussion
> and share your opinions. I am just comparing the security aspects of
> SSAS, the time efficient algorithm, to those of CGA.
>
> Thank you,
>
> Hosnieh
>
> *From:*Christian Huitema [mailto:[email-masked]]
> *Sent:* Saturday, March 16, 2013 5:37 PM
> *To:* Hosnieh Rafiee; [email-masked] <mailto:[email-masked]>;
> [email-masked] <mailto:[email-masked]>
> *Cc:* Erik Nordmark; [email-masked]
> <mailto:[email-masked]>; Ray Hunter
> *Subject:* RE: security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> It is very clear that if the attacker finds the private key, the size
> of the hash does not matter. But can you explain why you believe that
> retrieving the private key from the public key and a clear
> text/encrypted text pair is easier than breaking a hash? Did you
> somehow crack RSA?
>
> *From:* [email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]] *On Behalf Of *Hosnieh Rafiee
> *Sent:* Saturday, March 16, 2013 6:27 AM
> *To:* [email-masked] <mailto:[email-masked]>; [email-masked]
> <mailto:[email-masked]>
> *Cc:* Erik Nordmark; [email-masked]
> <mailto:[email-masked]>; Ray Hunter
> *Subject:* security consideration of CGA and SSAS - Ii-D action :
> draft-rafiee-6man-ssas
>
> Hello,
>
> attacker will need to do brute force attacks against the IID in order
> to generate the same IID as is generated by the use of CGA. In a CGA
> analysis paper they talk about a CGA security vaulue of pow (2, sec*16
> * 59) where 2 is the base and sec*16 * 59 is the exponential value and
> so they infer that by increasing the sec value used with CGA it will
> be safer, but this Is not true.
>
> key, modifier, and other required parameters) in the packet that was
> sent and I will have no problem in regenerating the CGA. My only
> because its security also depends on the Hash function that is used to
> generate the key pair and signature.
>
> **
> *Now the question is, Why not use a more cost efficient algorithm that
> afford you with the same security level as when using CGA. *
>
> I have also included the security group in this email so that they can
> also give me any comments that they might have.
>
> Thank you,
>
> Hosnieh
>
> ------------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Mar 2013 08:56:34 -0400

>>>>> "Jari" == Jari Arkko <[email-masked]> writes:

    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 that effort (2^59)/2 times,
    Jari> someone else is likely to hit the same key with a key pair
    Jari> that he or she controls, and an attack can be launched. What
    Jari> changes from RFC 3972 to your draft in this high-level
    Jari> analysis?

To repeat your analysis, in part so that *I* understand as well:

  a) CGA too expensive (generating new RSA) to calculate for nodes that
     want mobility and/or privacy.
yet:
  b) finding a hash collision takes, (2^59)/2 < effort to break RSA
     behind CGA.

So the expensive of the CGA exceeds the (cryptographic) benefit.

(a) is a concern for nodes that are moving, not for web servers.
(b) makes CGA possibly uninteresting even web servers.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Christian Huitema <[email-masked]>
Date: Fri, 22 Mar 2013 14:47:44 +0000

>  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 start with a repository of prime numbers, and then do something like:

For each trial
	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 will need an average of (2^48)/2 such trials, which means the catalog should have a size 2^24 or more. Granted, establishing that catalog will take some time, but it can be done once, in advance, before the IPv6 address is ever seen. The same catalog can be used for any IPv6 address.

-- Christian Huitema

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Mar 2013 16:52:23 +0200

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Mar 2013 15:29:51 +0000

> 	Check whether the resulting pattern matches the 48 bits in the IID

I think you can be quicker than that. Generating primes is easy
and starts from a random number. Picking two random numbers so
their product matches a bit pattern is easy. So long as the bits
you want from the RSA modulus aren't the least significant bits
then you'll win the game easily given the actual distribution of
primes. I've only briefly scanned the draft but it does seem
to be vulnerable in this way.

So I basically agree this approach seems fairly trivially broken
and that that's been sufficiently demonstrated on this list that
further discussion really ought wait for an updated I-D.

S.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 22 Mar 2013 18:23:42 +0100

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 prove my case. 
I want to thank everyone for their contributions on this topic and I hope
that you will bear with me and we can resume after I know something
definite. 
Thanks again,
Hosnieh