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

[Soatok Dreamseeker <[e-mail]>]

Hi Mike,

On Sun, Apr 11, 2021 at 10:56 AM Mike Hamburg <[e-mail]> wrote:
>
>
>
> > On Apr 11, 2021, at 10:52 AM, Soatok Dreamseeker <[e-mail]> wrote:
> > 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.
>
> 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.

That's good to know. Thank you.

> > 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.)
>
> 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.

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.

> > Regards,
> >
> > 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

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.