linux-kernel - Re: [PATCH 1/2] UUID: set multicast bit in pseudo-random MAC address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200710212109.18559.deller@gmx.de>
Date:	Sun, 21 Oct 2007 21:09:18 +0200
From:	Helge Deller <deller@....de>
To:	Theodore Tso <tytso@....edu>
Cc:	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
	Valdis.Kletnieks@...edu
Subject: Re: [PATCH 1/2] UUID: set multicast bit in pseudo-random MAC address

On Sunday 21 October 2007, Theodore Tso wrote:
> On Sat, Oct 20, 2007 at 09:58:40PM +0200, Helge Deller wrote:
> > Fix a bug in the current random UUID generator:
> > 
> > Section 4.1.6 of RFC 4122 states regarding the "NodeID" of a UUID:
> > :  For systems with no IEEE address, a randomly or pseudo-randomly
> > :  generated value may be used; see Section 4.5.  The multicast bit must
> > :  be set in such addresses, in order that they will never conflict with
> > :  addresses obtained from network cards. 
> > 
> > So up to now it was just pure ("random") luck if this bit was set or not.
> > This tiny patch sets the bit explicitely.
> 
> NACK.  Your patch degrades the random UUID by a bit, for no good reason.
> 
> The part of Section 4.1.6 which you quoted only applies to version 1
> UUID's --- i.e., MAC and time based UUID's.  Random uuids are version
> 4 UUID's, and are already distinguished from version 1 UUID's by the
> high 4 bits of the time_hi_and_version field, in octets 6-7 of the
> URL.  Hence, there is no danger of conflict.  If you had looked 3
> paragraphs later section 4.1.6:
> 
>    For UUID version 4, the node field is a randomly or pseudo-randomly
>    generated 48-bit value as described in Section 4.4.
> 
> And the summary can be found in Section 4.4 of RFRC 4122:
> 
> 4.4.  Algorithms for Creating a UUID from Truly Random or
>       Pseudo-Random Numbers
> 
>    The version 4 UUID is meant for generating UUIDs from truly-random or
>    pseudo-random numbers.
> 
>    The algorithm is as follows:
> 
>    o  Set the two most significant bits (bits 6 and 7) of the
>       clock_seq_hi_and_reserved to zero and one, respectively.
> 
>    o  Set the four most significant bits (bits 12 through 15) of the
>       time_hi_and_version field to the 4-bit version number from
>       Section 4.1.3.
> 
>    o  Set all the other bits to randomly (or pseudo-randomly) chosen
>       values.
> 
>    See Section 4.5 for a discussion on random numbers.

Hi Ted,

Thanks for looking into it and pointing to the important RFC pieces. 
Of course you are right and I mixed that up.

Herewith I withdraw this patch.

Helge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/