Subject: Re: [CFRG] please use real names (was: Re: Small subgroup question for draft-irtf-cfrg-hash-to-curve)

From: Squeamish Ossifrage <[email-masked]>
Date: Sun, 11 Apr 2021 12:15:19 +0000

Hi "Rene" (if that is your real name):

I would be curious to know how the quality of the research is different depending on whether it is signed ‘-=rsw’ or ‘Riad S. Wahby’.  Can you expand on that?

Shirley, using ‘real’ names would only make it easier to form preconceptions about the merit of an argument based on the name of who wrote it, no?  For example, wouldn't you expect much stricter scrutiny on an argument made by a queer carrion fowl calling themself Squeamish Ossifrage?  Nobody would give them a pass on the basis of nominal reputation!

If I were a spook who wanted to slip a back door or shoddy design into a standard for something like a PRNG or a PAKE, I would probably choose a boring name and quietly maintain a plausible-looking CV at a cryptography or networking company that nobody would bat an eye at, and then write long-winded discursive emails on an intimidating mailing list that discourages newcomers who aren't comfortably established in the field with their ‘real’ names (whatever it is that makes one name ‘real’ and another name fake).

Sincerely,
—Squeamish Ossifrage

P.S.  To keep this on-topic: The probability of a hash falling into a small subgroup is so small (e.g., ~1/2^252 for Curve25519) that any attack involving it necessarily implies a remarkable structured preimage attack on the hash function—or that you should have bought some lotto tickets instead of spending your time crouched over a glowing rectangle faffing around with hashes and curves.  If you chose a curve for which this probability was large enough to matter, you would be in serious trouble with rho anyway!

Similarly, for example, in AES-GCM there is an almost unimaginably larger probability, 1/2^128, of choosing an all-zero GHASH evaluation point, under which the authenticator is independent of the message content.  But the probability is so small that nobody cares.  And ‘But what if you abuse map_to_curve on its own in a place where the adversary can manipulate the algebraic structure?’ is no more an argument against the complete hash_to_curve design than ‘But what if you abuse GHASH on its own in a place where the adversary can manipulate the algebraic structure?’ is an argument against the complete AES-GCM design.

If you have a user who picks a password that hashes to a small subgroup, that's not a reason for failure—that's a reason to invite them to be coauthor on a paper (under a name they choose, which may not be the name a government has them under in a database that requires the help of a solicitor to change) in a flagship publication, about a novel attack on the hash function!

> Hi "rsw":
>
> As a general courtesy, may I suggest that all communications use
> people's real names and not some obscure acronym.
>
> The CFRG is supposed to be a research forum, where people do not hide
> their identity. In fact, in my opinion, IETF should have no place for
> communications by "anonymous".
>
> Rene
>
> On 2021-04-10 11:12 a.m., [email-masked] wrote:
>> Hello Feng,
>>
>> "Hao, Feng" <Feng.Hao=[email-masked]> wrote:
>>> Rsw also gave a similar example of having all zeros for the hash.
>>> Let me clarify that we are not – and shouldn’t be - concerned with
>>> any of such cases since the values are uniformly distributed within
>>> their respective range.
>> Right. And the argument is precisely the same for hash-to-curve!
>>
>> Let me be perfectly clear: the property that hash_to_curve gives
>> is that the output is a uniformly* distributed point in the (big)
>> prime-order subgroup of the target elliptic curve.
>>
>> At the risk of seeming didactic (in which case, apologies): the
>> identity element is indeed an element of the target group G.
>>
>> Put another way: fix a generator g of group G of prime order q. Then,
>> hash_to_curve returns g^r in G, for r sampled uniformly* at random
>> in 0 <= r < q. Under the assumption that discrete log is hard in G,
>> hash_to_curve does not reveal r. Under the preimage and collision
>> resistance of the underlying hash function, one cannot choose any
>> particular r or find two inputs that hash to the same r.
>>
>> I hope this helps clarify the security properties, and why focus
>> on low-order points at intermediate steps of the computation is not
>> relevant to the security of hash_to_curve as specified.
>>
>> * uniformly except for some statistical distance less than 2^-100.
>>
>> Regards,
>>
>> -=rsw
>>
>> _______________________________________________
>> CFRG mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>
> --
> email: [email-masked] | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 11 Apr 2021 12:42:26 +0000

For mere courtesy (besides, the "big" players tend to know each other, believe it or not), I too prefer that people use their real names, or at least those they're known under by their colleagues. 

Though I confess I pay more attention to something posted by, e.g., Hugo (as, regardless of whether I agree with his point or not, I found that it makes sense to consider what he says), than to something, e.g., posted by Squeamish (no offense meant): time is limited, flood of incoming email is out of control, some prioritization is a-must, and known correspondents do take precedence (obviously).

Critical? No. Fool-proof? No. Convenient? Heck, yes.

Oh, and I don't care who "Squeamish Ossifrage" is in real life, so no worries here. ;-)
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 4/11/21, 08:16, "CFRG on behalf of Squeamish Ossifrage" <[email-masked] on behalf of squeamishossifrage.se=[email-masked]> wrote:

    Sincerely,
    —Squeamish Ossifrage

---

From: Soatok Dreamseeker <[email-masked]>
Date: Sun, 11 Apr 2021 09:52:48 -0400

> Similarly, for example, in AES-GCM there is an almost unimaginably larger probability, 1/2^128, of choosing an all-zero GHASH evaluation point, under which the authenticator is independent of the m…

An additional observation.

- AES has a 128-bit block size
- When you use 256-bit keys, there are about 2^128 different keys that
will map a single 128-bit plaintext block to a single 128-bit
ciphertext block

However, I believe this probability of H=[0x000...000] is zero,
because the AES block cipher is a PRP and the input is [0x000...000],
and as far as I'm aware, there are no known (P, k) pairs for which
E_k(P) = P.

If AES were a PRF instead of a PRP, the risk calculus here would be
different. (But also, the 128-bit block size would need to be 256-bit
to reach the same security under birthday bound assumptions.)

Regards,

S. Dreamseeker <https://soatok.blog>

---

From: Mike Hamburg <[email-masked]>
Date: Sun, 11 Apr 2021 11:56:53 -0300

> On Apr 11, 2021, at 10:52 AM, Soatok Dreamseeker <[email-masked]> wrote:

Hi Soatok,

This is not an expected property of a PRP: for a fully random permutation,
we would expect about 1 element to map to itself in expectation for each key.
The existence or non-existence of known pairs (P,k) where E_k(P)=P doesn’t
rule out E being a PRP either way — e.g. it might be that there are no such
pairs, or that with the key you can easily identify such a P — but for an ideal
block cipher they would exist with overwhelming probability but would be very
hard to find.

> to reach the same security under birthday bound assumptions.)

Also, IIRC AES-GCM has better bounds with a PRF than with a PRP, because
you’d prefer the keystream to be uniformly random independent values instead
of uniformly random unique values.  That is, going to a PRF would remove
the birthday term in GCM’s analysis, though of course the PRF’s own security
analysis might itself have a birthday term.  This is how the analysis proceeds
for AES-GCM: note that any PRP is a PRF at the cost of a birthday term, and
then do the analysis for a PRF.

> S. Dreamseeker <https://soatok.blog>

My 2c on real names.  I think it’s preferable that we use real names if at all
practical, for a few reasons:

* Real names add a layer of professionalism that helps us not turn into
Reddit.  Which, while an interesting place, is arguably less productive than
CFRG, and is a safer space for e.g. racist jerks, because they can hide
behind pseudonyms.

* We need at least long-term pseudonyms to help remember, or even
research, who is making the which arguments.  Different people on these
forums have different styles.

* This body influences standards-setting organizations, so it may be
useful for legal reasons to keep track of who is sending in ideas (to
prevent, e.g., patent shenanigans).

There are legitimate reasons that someone might prefer a pseudonym.
Simply having a long-term handle isn’t a good enough reason, because
you could always sign as "Mike Hamburg (bitwiseshiftleft)” or similar.  And
we can’t keep people from coming up with a fake “real name”.  So I would
be happy with leaving this as a strong suggestion, rather than an absolute
policy.

Regards,
— Mike

---

From: Soatok Dreamseeker <[email-masked]>
Date: Sun, 11 Apr 2021 11:36:15 -0400

Hi Mike,

> block cipher they would exist with overwhelming probability but would be very

That's good to know. Thank you.

> then do the analysis for a PRF.

Yes, but a 128-bit PRF has different security properties than a
128-bit PRP, and a 256-bit PRF would generally line up better with
most cryptography users' expectations here.

> be happy with leaving this as a strong suggestion, rather than an absolute

Your proposal is reasonable.

Frankly, I was surprised to hear these arguments take place on a
cryptography forum, where anonymity experts are more plentiful than in
a random sample of the rest of the Internet.

Briefly: The risk of anonymity towards misbehavior is not because of
anonymity itself, but the removal of social consequences. As you
touched upon, long-term pseudonyms are preferable in forums where
reputation matters to one-time or short-lived pseudonyms.

Most of the participants on this forum do not know who Soatok is in
the government's perspective, nor would you be expected to care about
that. However, I do blog as Soatok, and my blog touches on
cryptography a lot. Additionally, I have open source cryptography
libraries (primarily written JS and PHP) on Github under this name.
You could say that my long-term pseudonym has "skin in the game".

Thus, my proposal is simply to include a preference for long-term
pseudonyms over short-term pseudonyms within the "strong suggestion"
that Mike proposed.

---

From: Mike Hamburg <[email-masked]>
Date: Sun, 11 Apr 2021 13:00:29 -0300

> On Apr 11, 2021, at 12:36 PM, Soatok Dreamseeker <[email-masked]> wrote:

Yeah, preferring long-term pseudonyms over short-term definitely makes
sense.  And while I don’t pretend to be an arbiter of pseudonyms, Soatok
has indeed published quite a bit under that name, and I don’t mean to
demand that they out themselves.

Also “real name” doesn’t necessarily mean “government name” anyway,
unless you really really need it to for some legal reason, which I’m pretty
sure we don't.  Requiring that Moxie Marlinspike post as “Matthew
Rosenfeld” seems plainly counterproductive.

— Mike

---

From: Michael StJohns <[email-masked]>
Date: Sun, 11 Apr 2021 14:37:47 -0400

> a random sample of the rest of the Internet.

Hi -

The main thing to remember is that the CFRG is a formal activity of the 
IETF/IAB/IRTF and as such is probably closer to a peer-reviewed content 
organization than anything else.  While I agree that there probably no 
formal rules preventing pseudonyms (I say probably, because I'm not 
actually sure how the IETF's IPR and Note Well rules interact here), I 
would also find it unlikely that the RFC series would publish documents 
authored under a pseudonym.

Keep in mind that's what's sauce for the goose is sauce for the gander.  
I imagine that there would be an uproar if a pseudonymous participant 
proposing a particular cryptographic construct were later found to be a 
member of a government body - or for that matter a sock puppet of 
another participant.

As I said in an earlier message, let's try and avoid culture wars here.  
If you've got a good reason for hiding your identity - I'm good with 
that.  If not, keep your pseudonym, but let us know who you really are 
so the non-l33t (yes, I know, dated) can follow along.  It's just 
professional courtesy.

Later, Mike

---

From: Michael Sierchio <[email-masked]>
Date: Sun, 11 Apr 2021 12:15:11 -0700

On Sun, Apr 11, 2021 at 11:38 AM Michael StJohns <[email-masked]>
wrote:
> ...

> ...

Plausibly non-hypothetical, I suppose.

I think it's fine to adopt a «nom de guerre», but I do confess
to an inclination to dismiss the comments of those who are
aiming at anonymity but manage to achieve absurdity.  It's very
nice that this group allows for amateur cryptographers (a
category that includes me).

I agree with you in requesting that participants let us know who
they are, or – if they believe they have good reason to hide
their identity – to say why they can't.

Cheers.

– M

-- 

"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 11 Apr 2021 18:17:17 -0400

It took me less than 30 seconds to discover the identity of the
'pseudonymous' contributor and a further ten to obtain an absurd amount of
information from public sources.

Why are we even having a discussion of pseudonymity when all that has
happened is someone didn't fill out the name field in whatever email client
they were using.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 12 Apr 2021 02:53:29 +0000

>happened is someone didn't fill out the name field in whatever email client

As someone pointed out long ago on the cypherpunks list, people get upset when
they see a post by Big Blue Hedgehog but are quite happy when it's from...
let's see, Bill.... uhhh, what's a good name... Door.  Yeah, Bill Door.

Peter.

---

From: David Jacobson <[email-masked]>
Date: Sun, 11 Apr 2021 20:43:48 -0700

There are a few cases where real names matter.   Suppose company X gets a patent on something.  The legal department at company Y wants to invalidate that patent by showing that there was prior art.  So they search all sorts of archived emails to find out if that something was previously mentioned.  Suppose they find what appears to be prior art.  If the email author was not one of the inventors, they might have grounds for invalidating the patent.  But if the email author was one of the inventors, then, according to my understanding, the patent is still valid in the USA.   (Maybe not in other countries.)  In order to find that out, they need to know the real name of the email author.

   David Jacobson

> On Apr 11, 2021, at 19:53, Peter Gutmann <[email-masked]> wrote:
>

---

From: Julia Hesse <[email-masked]>
Date: Mon, 12 Apr 2021 09:36:11 +0200

Dear fellow cfrg enthusiasts,

this discussion seems useless to me: we will not prevent anonymous 
submissions to our public mailing list. Because rarely there is a good 
reason for anonymity. Of course, most of the times it seems to be a 
choice of style. If you don't like the latter (I don't!), then why not 
just ignore such emails (I do!)?

I would prefer to go back to reading and discussing cryptographic topics 
on this list. If you want to keep discussing real names, then please use 
a separate thread instead of mixing it with the small subgroup topic.

Warm regards,
Julia Hesse