Two things about keys.

[jMyles]

(I'm going to try to write this in a way that doesn't use the word "key" constantly. And hopefully not at all.)

With the new names and placement of the keys (whoops, slipped up already) - I'm talking about receiving, delegating, and signing - I'm finding myself with a newfound sense of the pattern that is trying to emerge out of pyUmbral. This change is bigger and better than I realized at first blush.

This thought has occurred to me a couple of times before, but is really solidified in thinking about this change:

• one of the most important aspects of PRE is that it rethinks the narrative of who possesses which pieces of cryptographic material

For this reason, I have often preferred (and do currently prefer) that the pyUmbral system metaphor is material-based, rather than character-based, leaving the possession questions for higher-order abstractions, like we do in nucypher. Yet, when @cygnusv and I discussed the matter the other day, it still had a feeling of incompleteness in terms of the basis of the metaphor.

Two thoughts on this:

A) How many things? (x = 3?)

In this emerging model, with these three names: is three the right number of power structures representable by cryptographic material in the pyUmbral system metaphor? In the cryptology of nucypher, we see that 'receiving', 'delegating', 'signing' belong to respectively, Bob, Alice, and DataSource. (perhaps another case for rethinking DataSource's status as sub-character, but that's a different discussion).

It appears that we don't have a similar "-ing" name for Ursula. Here's where the rubber meets the road on that: https://github.com/nucypher/pyUmbral/blob/master/umbral/pre.py#L270

@cygnusv: Do you perhaps want to take a swing at choosing a different name for this object?

** a1) If indeed there are four such "special" objects: taken together as a collection, what is the proper name for this collection?

B) How many names: x/2 or x?

Currently, we have six such objects, but only three names.

After the refactor, I find that parameter names like encrypting_pubkey suddenly carry a stiffness and awkwardity by dint of the attached _pubkey or _privkey as a parameter name.

I assert that each of these objects, whether popularly regarded as "public" or "private", has a compelling name like receiving and delegating that simply and tersely explain the power they bestow:

• receiving
• sending (encrypting?)
• signing
• verifying
• delegating
• sharing (?)

In times where emphasis on sensitivity is required, we can, only in the case of the private part, call it receiving_secret or delegating_secret or whatever. If indeed this is a top-level concern, then I suggest that we need to implement (or outright move) some of the awesome logic we have in nucypher which creates ease around performing cryptographic tasks without needing to directly handle the secret part at all.

Now I can hear the rebuttal, "But divorcing these names in such a complete way produces confusion about which go with which, or even whether they're part of a pair of things at all!"

This is a reasonable critique, but consider that, outside the logic of key generation (ie, before these objects have even become differentiated into their intended purpose) and tests, this material almost never appears together; the possibility of misunderstanding the power dynamic in any local scope is unlikely. Additionally, as @michwill points out, these are, in every case, knowable by looking at the associated type hints.

...and if we find that we need to sternly associate them for some specific use case, then I suggest we're not suffering from bad names, but missing a useful layer of abstraction: KeyPair (or, in my heart of hearts, something like it, but which doesn't so vaguely and with wanton betrayal represent its actual underlying functionality as the "key" metaphor does).

---

I think that PRE has the power to move beyond "public key" and "private key" as a matter of its opinions on the nature of the material. While it's true that the "private" part is a hazardous secret, it is more importantly understood as the basis of a distinct sort of power. And where in all (or nearly all) previous cryptological schemes the interactions are discrete and two way (signing, encrypting), PRE has the power to expand the power of the material beyond ownership at all (for example, DisappearingAlice can create a scenario where important, functional cryptographic material is wholly in the public domain of the mathesphere or whatever).

(one final thought: @cygnusv: @tuxxy was telling me about a scheme you had been jamming on in your head in which even Alice can be known not to have the private key (ie, where the public key can be made by the Policy swarm itself) - maybe it's useful, for the purposes of future-proofing our names and metaphors, to also consider the evolution required to represent such a scheme. Do you have a link on this topic?)

---

• Rename "fourth corner" (currently sometimes called privkey_a_bn) deserves** a similar "-ing" designation
• In each case, give names to both objects in the pair.

[cygnusv]

In the cryptology of nucypher, we see that 'receiving', 'delegating', 'signing' belong to respectively, Bob, Alice, and DataSource. (perhaps another case for rethinking DataSource's status as sub-character, but that's a different discussion).

In the pyUmbral codebase, we've been using 'signing' to talk about Alice too, so Alice does both delegation and signing. This 'signing' is unrelated to DataSource since it's the signature of the KFrags (and hence, tightly coupled with delegation, actually). In fact, Umbral is (so far) DataSource-agnostic. Now that I think about it, is that something that perhaps we want to address? We could add data source signatures to encrypted messages at the pyUmbral level...

[jMyles]

In the pyUmbral codebase, we've been using 'signing' to talk about Alice too, so Alice does both delegation and signing. This 'signing' is unrelated to DataSource since it's the signature of the KFrags (and hence, tightly coupled with delegation, actually).

True. Maybe x=5 and not 4. :-)

In fact, Umbral is (so far) DataSource-agnostic. Now that I think about it, is that something that perhaps we want to address? We could add data source signatures to encrypted messages at the pyUmbral level...

Well, what exactly might we do in that scenario? Form an opinion over the signature scheme used by a DataStore? Does that make good sense do you think?

[cygnusv]

Well, what exactly might we do in that scenario? Form an opinion over the signature scheme used by a DataStore? Does that make good sense do you think?

We could follow the same we've already being using with signatures in other places: don't form an opinion on the signature scheme, just pass a function and provide a sensible default.