Hi, Rafiee,
I don't think using CGA by replacing the public key with a timestamp
or other random string is a "higher randomzation" address generation
method.
Hash is only one technique of generating a random like string, may not be
the best one among those specified in RFC4086.
ipv6-bou
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
Thank you. My question come from the so misleading Appendix A text:
"It discusses a (non-exaustive) number of
scenarios in which host privacy is still sacrificed even when
privacy/temporary addresses [RFC4941] are employed, as a result of
employing interface identifiers that are constant across
I kind did not understand the privacy issues of RFC4941 describbed in
Appendeix A.
To my reading and understanding of RFC4941,
RFC4941 specified to use privacy/temporary address defined as:
temporary address= subnet Prefix|| Randomized interface identifier
Randomized interface identifi
ipv6-boun...@ietf.org 写于 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_re
A new version of I-D, draft-zhou-6man-cga-hashagil-00.txt
has been successfully submitted by Sujing Zhou and posted to the
IETF repository.
Filename: draft-zhou-6man-cga-hashagil
Revision: 00
Title:Supporting Hash Algorithms Agility in
C
Regards~~~
-Sujing Zhou
ipv6-boun...@ietf.org 写于 2012-04-18 12:25:26:
> Hi, Karl,
>
> On 04/17/2012 09:58 PM, Karl Auer wrote:
> > A DHCPv6 server that allocates addresses linearly would be better
fixed
> > not to do so, than to go to the trouble of implementing stable
addresses
> > a la Gont
Hi，Huitema，
Regards~~~
-Sujing Zhou
Christian Huitema 写于 2012-03-29 08:23:38:
> Sujin,
>
> Your statement “after attacker has cracked a CGA address, then it
> is in the same stand as the defender” is incorrect. The attacker
Thank your for pointing out one of my omission that failing to r
Regards~~~
-Sujing Zhou
Christian Huitema 写于 2012-03-27 23:00:09:
> > Well, I think it is quite a simple trade-off. Increasing Sec
> increases computational effort on both sides by equal amount.
> Increasing the length of
> > the hash increases computational effort only on the attacker side.
In response to coments on draft draft-zhou-6man-mhash-cga-00
It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
a factor of 2^(16*Sec). It also increases the cost of brute-force
attacks by the same factor. That is, the cost of creatin
Regards~~~
-Sujing Zhou
Jari Arkko 写于 2012-03-27 16:21:52:
> Well, I think it is quite a simple trade-off. Increasing Sec
> increases computational effort on both sides by equal amount.
> Increasing the length of the hash increases computational effort
> only on the attacker side. As a resul
In response to coments on draft draft-zhou-6man-mhash-cga-00
1. It can be referred to RFC3972 section 7.2
"This increases the cost of address generation approximately by
a factor of 2^(16*Sec). It also increases the cost of brute-force
attacks by the same factor. That is, the cost of crea
hi,
what is the agenda for the 6man?
Regards~~~
-Sujing Zhou
ipv6-boun...@ietf.org 写于 2012-03-15 19:32:41:
> All,
> The preliminary agenda has been posted for the 6MAN meeting in
> Paris. We have the 0900-1130 slot on Tuesday morning.
>
> If you are willing to serve as a Jab
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Hi, all
I requested for a time slot (in pending status now ) for my newly
submitted draft draft-zhou-6man-mhash-cga-00,
in response to request of chairs, I give a short descriptioin here, any
comments are welcome.
the problems it solves:
The draft provides a simple method of enco
the problems it solves:
The draft provides a simple method of encoding multiple hash
function types in a CGA address, it can be thought of as
an improvement or an update to RFC4982.
the motivation:
RFC3972 defined CGA (cryptographically generated address) but only
use one hash
How can I ask for a presentation time slot?
Regards~~~
-Sujing Zhou
ipv6-boun...@ietf.org 写于 2012-02-29 03:08:51:
> On 2/28/2012 5:12 AM, Jeroen Massar wrote:
> > Hi,
> >
> > I was wondering, if anybody had a rough idea how many MLDv1-only
> > listeners are still out there in the wild. My assum
17 matches
Mail list logo
