On Fri, Nov 11, 2016 at 9:08 AM, Lennart Poettering <mzerq...@0pointer.de> wrote:
> On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) wrote: > > > The hostname may always be set manually and the result will (for the vast > > majority of people) be unique within their environment. This means that > if we > > are concerned with hostname leakage being a privacy issue, we need to > address > > that at the leakage point, not at the hostname point. > > > > Also, there are cases where hostname leakage may be used specifically > *because* > > it may be unique, such as one of several cues to the DHCP server. > Unfortunately, > > we cannot know in advance whether a DHCP server is going to be on a > trusted or > > untrusted network (we might be able to guess from the SSID of a WiFI > connection, > > but those are remarkably easy to fake). > > > > In short, I really don't think that the hostname is the right place to > solve > > this problem. If transmission of individually-identifying information is > a > > concern, then we really have to solve it at the transmission points and > not at > > the source. > > > > Yes, an argument could be made that a user who sets her own hostname is > > "opting-in" to that uniqueness, but I think that's setting an unrealistic > > expectation on all of our users that they fully understand the > consequences of > > that action. > > I still believe we should stick to a generic hostname by default, > (though I'd rather use "localhost" than "localhost.localdomain" in > order to drop the redhatism that "localdomain" is), and make the IPA > client-side enrollment code automatically update to a more "unique" > hostname if the hostname is found to be unset or be "localhost". > > I am also pretty sure that DHCP clients should suppress sending local > hostname information if the local hostname is unset or "localhost". > > > * I like Zbigniew and Lennart's thoughts on how to generate the "random" > suffix. > > the implementation I'd likely use is to take the first eight characters > of an > > md5 (or SHA) hash of /etc/machine-id and use those. That should make it > both > > repeatable and unique. > > Please do not use MD5 anymore. And please calculate your ID as > > SHA(x || k) > > x refers to the machine id, "||" refers to concatenation and "k" > refers to some app-specific key (which is OK to be publically > known). It's important to concatenate the app-specific key, so that it > is not possible to map the machine IDs used by one app to the machine > IDs used by another.. > /me dons crypto hat. SHA(x || k) has three problems, one of which is bad enough to be an absolute showstopper. 1. Specify *which* SHA. SHA-1 should not be used for new applications. 2. Concatenation without some additional property preventing collisions of the hashed data is problematic. In particular, if you shorten x by a byte and prepend the same byte to k, you get the same output. This is probably irrelevant for this particular use case, but it's still a sign that the construction is bad. 3. The SHA hashes, like all Merkle-Damgård hashes, is subject to length-extension attacks. In particular, if x is a multiple (or slightly above a multiple) of the block length, then anyone who learns SHA(x) can efficiently derive SHA(x || k). This basically removes all security from this scheme. HMAC(k, x) would be much better. But I think this protocol is generally more fragile then needed. How about generating a per-app-installation random value and HMAC-ing *that* with the machine id? --Andy
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
