Current way is through methods in BigNum and Point classes. But perhaps it has more sense to offer such methods in Umbral keys. We can of course offer them in both places, but it seems more likely to be used in Umbral keys.

Related:
nucypher/nucypher@53a0a33#diff-f8cdf78f1ab20bfd277c9666b059217eR115

Hi, I want use This Package(code) for my project ( it also to be open-source )
but I can't find License info of pyUmbral
Could I use this code as open source?
I want know more detail about License of pyUmbral :)

Thanks,

I don't exactly understand what is being asserted here.

Perhaps, "This capsule doesn't appear to have been made for this public key" ?

In other words: Is this a general-purpose proxy reencryption library? Or a framework for making KMS's?

After coding most of Umbral with the current Point class, I have to say that currently it feels weird because it uses an additive notation (i.e., points are added and multiplied by a scalar, rather than multiplied and exponentiated, respectively). The problem is basically with the EC multiplication operation and how it is overloads the Python * operator. Right now, multiplying a point by a scalar looks like this: point * scalar, which is very odd since it doesn't look like the usual two ways in the literature to express this:

• Additive notation: scalar * point
• Multiplicative notation: point ** scalar

I'm afraid there is no solution for this if we want to follow the additive notation. Therefore we can either just leave it like that, or change it to multiplicative notation (like in Charm). The latter implies that EC addition becomes multiplication (*), and that EC multiplication becomes exponentiation (**)

It seems that after all, cryptography.io had AEAD implementations (although in the hazmat module, but that's OK).

https://cryptography.io/en/latest/hazmat/primitives/aead/

We could update UmbralDEM (as per #29) to use this instead NaCL's Secret Box. This is not a priority, but I would like to have the possibility to use the Associated Data part of the AEAD to improve the overall integrity of the (capsule, symmetric ciphertext) bundle.

Currently, UmbralParameters is an input parameter of split_rekey() and reencrypt(), but not in encrypt() and decrypt(). Strangely, it is a parameter of internal functions like _encapsulate(), _decapsulate_original() and _decapsulate_reencrypted().

I propose to remove it from the internal functions, and put it only in the public facing ones.

Hi,
I have been using pyUmbral and am researching a distributed ledger information sharing design which incorporates pyUmbral. You can read about it and see a diagram here

In short what I am wondering is ... could the encrypt function [1] be overloaded to just return a cipher (and not both the cipher and the capsule)? Perhaps just another/different function capable of producing only a cipher of Alice's plain text would suffice.

The reason that I need this is I want to demonstrate that chunks of encoded/compressed and encrypted (byPyumbral) data can be stored in the blockchain state (either as a message -> transaction or as a state variable in a smart contract). An example of this would be storing firstname, lastname, address etc. as only a cipher. Then, in the event that someone (like a delivery driver) needs only an address (and none of the other important/private information which is encrypted by pyUmbral in the blockchain) the software/app can fetch this specific information from the blockchain (decrypt and decompress to plain text) and then encrypt it using the current encrypt function (producing the cipher of this specific information as well as the new capsule for the whole proxy re-encryption process as it stands).

Please have a read of the overview of the idea and let me know what you think. I would love to create a demo (even if it is using Vyper smart contract on Ethereum etc.) so that we can show how sustainable p2p e-commerce could work using NuCypher.

Many thanks

[1]

Let's include the curve_nid in the bytes of a Capsule so that Ursula can know which curve was used to create it.

Instead of having a separate protocol for verifying correctness ("the challenge protocol") we can simply integrate it as part of the re-encryption request and reply.

Basically, the idea is to include the challenge request as part of/together with the Capsule, and put the challenge response as part of the cfrag. The disadvantage of that is that we are adding a communications overhead for all re-encryption requests (i.e., metadata such as timestamp to avoid replays) and re-encryption responses (i.e., around 5 or 6 points/bignums). The advantage is that we get rid of supporting an additional protocol, and on top of that, we always get correctness guarantees on each re-encryption.

We are using the term "encapsulate" as a sort of loanword from vanilla KEM schemes. Thus, we also inherit the derived noun "Capsule."

But what is a Capsule? Here's a dictionary definition from MW that is the best for our purposes among their options:

noun cap·sule \ ˈkap-səl , -(ˌ)sül also -ˌsyül \ a compact often sealed and detachable container or compartment

So, when I was reading the code, following test_m_of_n, I expected the following narrative:

• Bob, via a side-channel, finds out that there is A Secret that is meant for his eyes.
• Bob seeks at least m Ursulas, getting from each of them a CapsuleFragment
• Once Bob finds that he is in possession of a Critical Mass of CapsuleFragments, he is able to assemble ("reconstruct") a Capsule (in this case, we've been calling it a ReconstructedCapsule) and open it, finding The Secret inside.

However, here's what actually happens:

• Alice informs Bob of A Secret meant for him, and gives Bob a bulk ciphertext, which includes a Thing. Heretofore, we've called this thing a Capsule.
• Although Bob is made to believe that the Thing is a capsule, he doesn't open it. Instead, Bob gives the Thing to at least m Ursulas.
• In return, each Ursula gives Bob a CapsuleFrag.
• Bob is able to combine these CapsuleFrags to make a Capsule (again, this is a ReconstructedCapsule).
• Bob opens this (reconstructed-) capsule, and The Secret is inside.

So what is the Thing?

It's not a Capsule by the dictionary definition to anyone other than arguably Alice, who finds that she can open it and peer inside.

As I read the code, this blocked my ability to reason about it and move forward. It is clear that the thing that Alice gives to Bob is not a Capsule in any meaningful way, and in fact Bob does not use it the way a Capsule is used in a KEM scheme if I understand correctly.

Moreover, I have been left with a sense that these two things are actually things of the same shape, and are maybe even the very same thing (recall my proposal that they inherit from the same class).

Then @tuxxy made [this proposal|https://github.com//pull/9#discussion_r159512006] which I think makes sense:

Would it be beneficial to add Bob's components to the Capsule object and have them be None initialized by default?

This way when Bob reconstructs it, it's the same capsule object? The addition of these properties would simply be a method on the class or something.

This makes a great deal of sense to me. Then, the life of the capsule is such that:

• Alice creates the Capsule.
• Upon creation, Alice can open the Capsule (ie, capsule.is_openable_by_alice == True).
• Then, she gives the Capsule to Bob, who is unable to open it - it is only openable by Bob once it has all of a Critical Mass of fragments adhered.
• Bob gathers the CapsuleFragments in the usual way: handing the Capsule to Ursula for examination.
• Once Bob has adhered a Critical Mass of CapsuleFragments to the Capsule, it becomes openable_by_bob.

I'm not sure this is perfect, but it is the best metaphor I've heard yet. I think it makes the narrative of the decapsulte_reencrypted method far, far clearer.

Throughout umbral.umbral, classes have one-letter attributes. What are these?

(I imagine perhaps v is version?)

It is possible to make capsules in such a way that it's impossible to reencrypt them to others. Do we want this? I guess we do.

Add a classmethod to the Capsule and related fragment classes to return the expected length of the object serialized as bytes given a specific curve.

Moving discussions between @cygnusv and I from Email to GitHub!

The Umbral data classes need to have a serialization format. This involves the classes:

1. RekeyFrag
2. CiphertextKEM
3. CiphertextFrag
4. CiphertextCombined
5. ChallengeResponse

Inside of these classes, we don't have very informative names, so maybe we should also consider some naming here so auditors can have an idea of what each component is.

As you can see from my PR, I had called this encrypted key a combined_critical_mass.

But since we always run decapsulate on it, does it make sense to call it a Capsule?

The current problem with the multi-curve support for tests (#54) is caused by a lack of consistency of the parameters in use (#99). Apart from solving that problem, it's probably a good idea to include some additional checks so it's not possible to have stuff with different parameters (e.g., different curves) at the same moment.

I quoted @Tux in #11, saying "I don't think we're finished in entirely building out this layer yet. [Point and Bignum] should not be implemented, in the raw, on the KMS."

So: are we going to do a Key class?

I'm in a holding pattern on our Bob class in the KMS until either a Key API is available or we develop a temporary shim to make the PublicKey class that we use in the KMS compatible with Bignum / Point.

Currently, we have a number of untested code snippets in the docs. These need to be tested to ensure that they don't grow stale as the code evolves.

If Bob is in the process of attaching CFrags to a Capsule, and he then serializes to bytes, don't we want to represent the CFrags in the resulting bytestring? Currently, they're ignored.

We currently have two different ways of producing public and private keys in Umbral:

• Through the PRE class:

    priv_key = pre.gen_priv()
    pub_key = pre.priv2pub(priv_key)

• Through the UmbralPrivateKey class:

    priv_key_alice = keys.UmbralPrivateKey.gen_key()
    pub_key_alice = priv_key_alice.get_pubkey()

I'd prefer to have just one, preferably the second. What do you think?
As mentioned in my last issue, I'm preparing a small PR so I can make this change if you agree.

Is it possible that we'll only have _point_eph_e_prime and not _point_eph_e

I've been thinking about the removing ReconstructedCapsules because I think they don't have enough justification. You see, only Capsules and cFrags will actually see the Real World (i.e., being serialized, stored and sent over a network). On the contrary, ReconstructedCapsules only make sense as an intermediary state after the moment that Bob takes a bunch of cFrags and combines it, but before he decrypts it. I don't see why Bob would need to save this state. The only exception I see right now is if he wants to decrypt it again in the future (in this case, he only needs to decrypt the ReconstructedCapsule, and doesn't have to bother about cFrags and their combination).

So, my question is: is this last exception enough to justify the existence of ReconstructedCapsule?

Just a thought: if I had put the code of Combination (currently named Reconstruction) inside the decryption when I designed Umbral, then ReconstructedCapsules wouldn't exist right now.

By the way, just to let you know that for the Umbral paper, I already dropped the ReconstructedCapsule concept. Instead, Bob's decryption simply takes the cFrags as input and combines them inside. Anyway, this doesn't affect whatever we decide for the code of Umbral.

In test_umbral, we reuse this same set of parameters for values of m and n in several tests:

    (1, 1),
    (3, 1),
    (3, 2),
    (5, 4),
    (10, 8),

I think it makes sense to have a quick comment next to each of these explaining what new thing is tested by virtue of including it. So:

    (1, 1),  # Works with a single kfrag.
    (3, 1), # Works when n is > 1, m is not.
    (3, 2), # Works when both are greater than 1.
    (5, 4), # ???
    (10, 8), # ???

Hi,
Just curious about the best installation option. I am using the following command and receiving the warning shown below.
Many thanks
Tim

sudo python3 setup.py install

/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg)
/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'extras_require'
warnings.warn(msg)
running install
running build
running build_py
running install_lib
running install_egg_info
Removing /usr/local/lib/python3.5/dist-packages/umbral-0.1.egg-info
Writing /usr/local/lib/python3.5/dist-packages/umbral-0.1.egg-info

On Slack, @michwill said:

Btw with regards to Umbral I have the following thought. With encapsulate() and decapsulate(), one can easily implement encrypt() and decrypt(). But I think we need to make encrypt and decrypt methods for users

Maybe PRE class should also subclass something which creates encrypt and decrypt functions using any algos which implement encapsulation

In a way, we can have a mixin which implements encrypt/decrypt using encapsulate/decapsulate, separately from umbral.py. IMO that's important for users of umbral.
And also I think that this mixin should be in pyumbral, not nucypher-kms

Subsequently, the following conversation ensued:

jmyles [1:35 AM]
@michwill: In principle, I agree in full. In practice, I find that I react with more nuance:

1. I'm not sure that "we" in the sense of PRE authors and reference implementers need to make encrypt and decrypt, but surely "we" as demonstrars of the capacity for PRE to perform as a cryptographic scheme of viable social worth need to do so, yes.

2. I don't like the idea of PRE being a subclass, mostly because I don't like the idea of PRE being a class.

3. Yes, this mixin was among the scenarios I had imagined when I tried to summon the needs of "other implementers" in my early conversation with @dnunez and @Tux.

4. I agree that such an instrument belongs in pyumbral.

Let me suggest a name for this facility:

Capsule.

Picture this:

...
  def encrypt(self, *args, **kwargs):
     return NotImplemented

class WidelyUsefulDEM(object):
...
   def encrypt(self, payload):
      bulk_data, encryption_key = self.perform_locally_relevant_encryption(payload)

    self.encapsulate(..., encyrption_key)

class CapsuleWithDEM(WidelyUsefulDEM, Capsule):
    ...

    def transmit_via_network(network_params):
        ...

(edited)
[1:37 AM]
And then, PRE, by contrast, is singular and fixed, set as stubborn singletons in a module, using only names to be found in the paper and representing them exclusively as bytes. (edited)
[1:39 AM]
(going to bed; see y'all in the morn)
michwill [2:05 AM]
Huh, having encrypt in a special Capsule is interesting. If it makes a convenient API of course

dnunez [10:25 AM]
I really like the idea of class WidelyUsefulDEM
[10:26 AM]
but not so much that encrypt is a method of Capsule
tux [10:27 AM]
Yeah, I do too
dnunez [10:27 AM]
it doesn't make sense from the OOP point of view
[10:27 AM]
you don't encrypt a capsule
tux [10:27 AM]
Right
dnunez [10:27 AM]
actually a capsule is just the information you need to decrypt later
[10:28 AM]
encapsulate returns a tuple (symmetric key K, capsule)
[10:28 AM]
K is used during the symmetric encryption (edited)
tux [10:29 AM]
Yeah, a DEM class sounds good to me
dnunez [10:29 AM]
and the final ciphertext is (capsule, symmetric ciphertext)
[10:29 AM]
as you can see, during the symmetric encryption you don't use the capsule for anything
[10:30 AM]
it however must be present for decryption, since you first need to decapsulate the capsule to obtain again K
tux [10:30 AM]
Right
[10:31 AM]
@dnunez what about putting a nullable attribute on Capsule plain_key?
[10:31 AM]
Then for symmetric encryption, you could pass in the capsule.plain_key (edited)
dnunez [10:32 AM]
The idea of class WidelyUsefulDEM has some other advantages, since for example, the KDF right now is producing a fixed amounts of bytes (32, if I'm not wrong), so this could be retrieved from the WidelyUsefulDEM instance
[10:32 AM]
but I see this instance as something that is used in PRE, not in Capsule
tux [10:33 AM]
Yeah, that makes sense too
dnunez [10:35 AM]
could you explain more the nullable attribute thing?
tux [10:36 AM]
When you create a capsule, instead of returning a tuple it just adds the key to a plain_key attr
[10:37 AM]
Then on encrypt, you pass in the capsule with the plain_key
[10:37 AM]
If it doesn't exist, it'll error
[10:39 AM]
On decrypt, it either a) decrypts the capsule and then performs symmetric decryption or b) checks for plain_key before trying to do symmetric decryption.
[10:41 AM]
It'll never be serialized and transferred to anyone, it only exists locally. After performing one encrypt, we del the plain key attr.
[10:41 AM]
Probably still can be recovered in memory though
dnunez [10:52 AM]
mmmmm
[10:54 AM]
well, that's kind of compatible with @jMyles idea
[10:54 AM]
that's a good
tux [10:55 AM]
Now, this attr can also be on PRE
dnunez [10:55 AM]
I still think that my point wrt "you don't encrypt capsules" is still valid
tux [10:56 AM]
That too makes sense
[10:56 AM]
Right
dnunez [10:56 AM]
but the idea of including the key K in the capsule could be acceptable
tux [10:57 AM]
It can work, doesn't mean it should though
[10:57 AM]
I'm kinda leaning towards having it in the PRE object
jmyles [12:32 PM]
@dnunez: But look at my example above - you're right! Capsule doesn't have encrypt. It's a mixin that, when used with WidelyUsefulDEM becomes CapsuleWithDEM, and that has encrypt.
[12:33 PM]
You don't encyrpt a Capsule, that's true, but that's not the only way to think about OOP verbs. In this case, consider that you "encrypt into" a CapsuleWithDEM.
[12:36 PM]
I don't like it being on the PRE because I want PRE to be stateless and singular. I don't want the user mixing it with anything, even a WidelyUsefulDEM. The PRE needs to be something like a homomorphic translation of the paper.
[12:36 PM]
(ie, I don't think that PRE is properly a class, but a module with functions and private constants) (edited)

I propose, as I have a few times on Slack, making PRE a module, which does UmbralParameters stuff at import time (with some global configuration options available) and just worked.

This line appears in our codebase 18 times:

pre = umbral.PRE(...)

If we don't do something about it, it will end up sprayed all over our user's codebases as well.

Let's get it out!

There are certain places where Alice's private key is used for signing data (e.g., signature of kfrags). This should be avoided.

This implies that a separate pair of signing keys or a signing function should be passed in. This can be made as an optional argument, so in case this is not provided, then the original approach (i.e., using Alice's private key) is used, since it's better than no signature at all.

The Capsule and Fragment classes are quite lengthy due to serialization code, would it be ideal to move those out into their own files and import them in the umbral file?

I got PRs pulled into Cryptography.io for implementing and exposing BN_clear_free from OpenSSL.

This improves the security upon BN_free by first zeroing out the memory then freeing it.

We should use BN_clear_free in places where there are private values (ie: practically everywhere).

There are five tests - the last four of which look very interesting - commented out. Where are we on these?

Currently, Umbral generates encrypting keypairs randomly. That's fine, but we should also support KDF-based generation, since we are going to need it for tagged capsules.

Per late-night banter with @tuxxy, I owe tests for this logic.

Implement BLAKE2b for the KDF instead of SHA512. Pretty straight forward.

UmbralDEM needs to take arbitrary AEAD ciphers. This will allow some people to use AES-GCM and others to use ChaCha20-Poly1305, or any other cipher they want to use.

A Key class might be created.

This is a discussion of scoping. What should be included in the key class? I propose serialization through cryptography.io DER formatting.

What else should this do?

Reminder: this should be specific to the reference implementation of Umbral, not the KMS itself.

The title speaks for itself.

A public key cannot derive another public key.

Until @tuxxy corrected me this morning, I was under the impression that this project was ready to begin implementing in the KMS.

Quoting @tuxxy:

Point and BigNum are utility classes for us to implement the Umbral schema in a way that works better as a layer between OpenSSL and Cryptography.io. I don't think we're finished in entirely building out this layer yet and these should not be implemented, in the raw, on the KMS. I'm leaning towards developing a Key class (need to talk to David about this) in Umbral and allowing you either to inherit it or build a new Key class that has an umbral.Key as a property or something.

Putting aside for a moment the matter of whether a Key class is or isn't a good idea, do y'all (@cygnusv and @tuxxy) have a sense of when we can start to move some of the KMS logic from the current crypto API to pyumbral?

About using the name capsule_maker_public_key to describe the public key used to (I believe) verify the accuracy of the activated components during decapsulation, @cygnusv says:

Opener_private_key is OK, but capsule_maker_pub_key it's not, since in principle anyone (even if they don't have any keys) can be a capsule maker. Anyway, this is just a comment on naming. Let's simply put it in our TODO list.

However, doesn't this indeed need to be the very key that was used in the original encapsulation? And isn't someone who encapsulates a capsule maker?

Or have I missed a crucial detail? :-)

Currently Umbral and all its auxiliary code is implemented in a single file, where all the PRE functionality is included in the same class. Does it make sense to separate the code according to the characters?

• Alice: encapsulate, decapsulate_original, split_rekey
• Bob: decapsulate_reencrypted, check_challenge
• Ursula: reencrypt, challenge

Before that I came up with the zero-knowledge verification protocol, the kFrag consistency thing was the best thing we had. But now it seems not very useful. Let's recall what it achieves.

vKeys are produced by Alice during split re-encryption key generation, and distributed to all Ursulas together with each kFrag, so they can check whether their kFrag is consistent with the rest. "Consistent" here means that all kFrags encode a common shared secret. However, this doesn't check anything regarding the actual validity of this shared secret, which in our case is a re-encryption key.

So it's possible right now that a cheating Alice creates a consistent set of kFrags so the consistency check passes on each Ursula. However, this will be detected by our fancy zk-validation protocol once Bob sees that decryption fails on his side.

It seems then that the only way it is useful is to detect situations where there is a small subset of erroneous kFrags (which may be intentionally or not), but that the rest are OK.

Currently we generate random numbers via urandom and check to see if they're a valid private key.

We can use the OpenSSL BN_rand functions to do this instead. I've exposed these in cryptography.io: pyca/cryptography#4118

In PRE.reencrypt, instead of raising an error, perhaps we want to give a indistinguishable garbage.

Some tests do something weird, IMHO. Instead of using Alice and Bob as delegator and delegatee, they use Alice for both. For example:

def test_challenge_response_serialization():
    priv_key = pre.gen_priv()
    pub_key = pre.priv2pub(priv_key)

    _unused_key, capsule = pre._encapsulate(pub_key)
    kfrags = pre.split_rekey(priv_key, pub_key, 1, 2)

Is this intentional? If so, what's the rationale for that?
I'm currently preparing a PR with some improvements, so I can change this if necessary.

Creating new keys is really cumbersome having to add the parameters every time gen_key is called.

This should be handled similarly to how we handled this with the PRE object.

Does it make sense to change umbral.umbral.RekeyFrag to something like umbral.fragments.KFrag, and then deprecate nkms.crypto.fragments.KFrag in the KMS repo?

That will certainly make my code simpler.

Currently, all tests are performed using secp256k1. We should implement a test that uses a curve with a different key size to verify agnosticism.

Hi,
I am trying to run the demonstration as presented by John Pacific at < https://www.youtube.com/watch?v=x-HYMufPhVo >

It seems that the code here in nucypher pyUmbral is different to the code in the above YouTube demonstration.

For example running the following command

alice_pub_key = alice_priv_key.get_pub_key()

as per the video demo results in the following error

AttributeError: 'UmbralPrivateKey' object has no attribute 'get_pub_key'

If I run the following command to peer into the Umbral library's functions

dir(keys.UmbralPrivateKey)

I see that there is a function called get_pubkey (as apposed to the above get_pub_key)

I also note that the umbral.PRE() method is missing from the code base.

Is it possible that the umbral code is out of sync with what was used in the video demo? Or is there another place I can get code to perform the same task (as the video demo) on my own PC?

Many thanks
Tim

We need to deterministically generate the Umbral parameters h and u.

In umbral.py, we use constants from pynacl, e.g.:

    key, capsule = _encapsulate(alice_pubkey.point_key, SecretBox.KEY_SIZE)

But for the cipher, we actually use cryptography.io/openssl. In dem.py:

        self.cipher = ChaCha20Poly1305(symm_key)

We need to use consistently either one, or the other