<div><div dir="auto">I was using salt in the sense you’re using pepper :)</div></div><div dir="auto"><br></div><div dir="auto">And in my subsequent note, I was indeed suggesting a common service.  It could be run by icann or by another group.  </div><div dir="auto"><br></div><div dir="auto">Steve</div><div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 6, 2019 at 6:14 PM joe <<a href="mailto:joe@stsauver.com">joe@stsauver.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
You mentioned:<br>
<br>
> I understand the<br>
> intended use, and it looks like you're simply using this as a salt.<br>
<br>
Actually, the secret value is being used as a pepper, not a salt, see<br>
<a href="https://en.wikipedia.org/wiki/Pepper_(cryptography)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Pepper_(cryptography)</a><br>
<br>
> Therefore, why not generate a suitably strong salt?<br>
<br>
A per-entry salt wouldn't yield the same hashed output for two cases<br>
where the same input was presented and processed. That property is great<br>
(and exactly what we want if we're creating salted passwords and we want<br>
to ensure that someone reviewing hashed passwords can't spot accounts<br>
that share a common password), but in this case we WANT the ability to<br>
identity different domains with the same point of contact information<br>
(even if that's only within a given registry's portfolio of domains).<br>
<br>
Quoting <a href="https://en.wikipedia.org/wiki/Salt_(cryptography)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Salt_(cryptography)</a> , "Since salts are<br>
different in each case, they also protect commonly used passwords, or those<br>
users who use the same password on several sites, by making all salted hash<br>
instances for the same password different from each other."<br>
<br>
In the instant case, however, we WANT the same input to yield the same<br>
hashed value so that domains with the same point of contact details can<br>
be identified and linked, just as it used to be possible to use reverse<br>
Whois search engines to look up all domains that had the same point of<br>
contact phone number "555-867-5309" (or whatever).<br>
<br>
If hashing were to be done as proposed:<br>
<br>
-- we'd find a domain of interest and look up its *hashed* values in Whois<br>
-- we'd then check for other domains which have the same hashed value or<br>
   values in Whois (I'm assuming that commercial reverse Whois providers<br>
   would step up to the plate to handle the mechanics of that, just as they<br>
   did for non-hashed Whois).<br>
<br>
We could thus link the domains, even if we couldn't link those domain to a<br>
particular meat-space identity.<br>
<br>
> If you want to use<br>
> something related to strong crypto keys, then I guess the way to do it<br>
> would be to generate a public-private key pair and use the *public* part as<br>
> the salt.<br>
<br>
The pepper doesn't need to be related to strong crypto, it just needs to be<br>
a long, random and secret value.<br>
<br>
With a secret pepper, users can still "buy mappings" one at a time by<br>
registering domains with specific details of interest and then seeing<br>
what "pops out" (in hashed form) in Whois.<br>
<br>
But for fields of reasonable length, purchasing all possible values<br>
for each registrar would be prohibitively expensive.<br>
<br>
And even if I know a few hundred or thousand plain text-to-hashed mappings,<br>
that will not let me derive the secret pepper even if I know the algorithm<br>
used, the plain text, and the hashed result.<br>
<br>
> Question: Can you say more about the reasoning related to different keys<br>
> (salts) across different registries?<br>
<br>
A common pepper shared across hundreds or thousands of parties<br>
( <a href="https://www.icann.org/registrar-reports/accredited-list.html" rel="noreferrer" target="_blank">https://www.icann.org/registrar-reports/accredited-list.html</a> ) would<br>
"leak", and any such "leak" would be non-attributable since every registry<br>
would know the same common secret, and fingers would be pointed hither<br>
and yon.<br>
<br>
A unique pepper created at each registry and never exported to any third<br>
party would limit that exposure, and each registry would presumably exercise<br>
appropriate care to secure their pepper (since failure to do so would likely<br>
result in litigation, regulatory penalties, loss of market share, etc.)<br>
<br>
> I understand that it might be hard to<br>
> design a system that yields the same hash across all registries -- and all<br>
> registrars for a thin registry -- so that might be the reason for your<br>
> decision,<br>
<br>
I'd love to have comparable hashes (same input --> same output) for ALL<br>
registries, but that will only be possible if a single central authority<br>
(ICANN itself?) were to perform all the hashing. My subjective impression<br>
(which may be wrong) is that ICANN would shy away from performing such a<br>
role.<br>
<br>
> but that seems like a decision determined by the pragmatics of<br>
> keeping the salt(s) safe and not because it was the preferred result.<br>
<br>
I'm a very pragmatic person, and domain Whois is a very pragmatic topic,<br>
sorry about that.<br>
<br>
My preferred result would be for natural persons who are concerned about<br>
the exposure of their personal data to just use Whois proxy/privacy services,<br>
status quo ante (e.g., as was previously the case).<br>
<br>
However, because that is apparently not sufficient in a GDPR-enhanced<br>
world, the hashing option is the best technical option I've been able to<br>
come up with for domain Whois that will preserve at least some ability to<br>
identify multiple domains that are all controlled by a common party.<br>
<br>
Is it perfect? No.<br>
<br>
But will it be better than the currently crippled domain Whois system?<br>
Yes, I think it would be.<br>
<br>
> This<br>
> issue leaped out at me as I read through the document and when I got to the<br>
> FAQs, I saw the question was asked but the answer was simply it was an<br>
> intentional design choice.<br>
<br>
Thanks for reaching out, and let me know if there are other questions I<br>
can help address.<br>
<br>
Regards,<br>
<br>
Joe<br>
</blockquote></div></div>