Some more naming things, some more questions. #9
Conversation
…int for ReconstructedCapsule.
| else: #if len(reencrypted_keys) == 1: | ||
| return ReconstructedCapsule(e_prime=cFrag_0.e1, v_prime=cFrag_0.v1, x=cFrag_0.point_eph_ni) | ||
|
|
||
| def decapsulate_reencrypted(self, pub_key, priv_key, ctxt_combined, orig_pk, orig_ciphertext, key_length=32): | ||
| def decapsulate_reencrypted(self, pub_key: Point, priv_key: BigNum, orig_pub_key: Point, | ||
| recapsule: ReconstructedCapsule, original_capsule: Capsule, key_length=32): |
There was a problem hiding this comment.
So, @cygnusv and @tuxxy, as I look toward implementing this stuff in the KMS, this is the epicenter of my wonder so far.
I notice (and have pointed out here via type hints) that public keys are Points, while private keys are BigNums.
-
How do you propose working that into the KMS codebase, where we have classes for these things? Shall we start using Point and BigNum as the basis for keys up there as well?
-
In these tests, we show the person calling this function (presumably
Bob) having possession of both capsules. Doesn't this function need to work withBobonly having access to theReconstructedCapsuleinstance (which in tests we callcapsule_bob)?
There was a problem hiding this comment.
No, 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.
TL;DR: the Point and BigNum classes aren't meant to be used or handled outside of Umbral.
There was a problem hiding this comment.
OK, so in a nutshell, pyumbral isn't ready to be used for the KMS yet? In that case, I misunderstood its status.
Any ideas about my question 2?
There was a problem hiding this comment.
Regarding 2: We could do it either way. I agree that it can be perceived as more natural if Bob has everything he needs in the ReconstructedCapsule, but it happens that all the components of the original capsule are needed for Bob's decryption, in particular, during the private correctness check by Bob, so I preferred simply to reuse the original Capsule rather than overload all the cFrags and the ReconstructedCapsule with information that Bob already has in the original Capsule.
There was a problem hiding this comment.
@cygnusv 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.
There was a problem hiding this comment.
@tuxxy: That's getting closer to a metaphor that makes sense.
The Capsule starts as something that is openable_by_alice, and only when Bob adds a critical mass of CapsuleFrags does it become openable_by_bob.
That's much clearer I think.
There was a problem hiding this comment.
mmm not exactly, Bob doesn't need the original Capsule to open the ReCapsule (i.e., he can compute the derived symmetric key without it), but he needs it to check the validity of the ReCapsule (in the sense of having a guarantee that the ReCapsule is indeed related to the original Capsule). Something similar happens with the check_challenge method, where Bob also needs the original Capsule to check the correctness of cFrags.
One could then say that the correctness check during decryption could be made separately, but cryptographically it's much better to return an error as the result of the decryption in case this check fails, instead of letting the user obtain a "wrong" response (e.g., this could be used to attack Bob).
| @@ -13,7 +13,7 @@ | |||
| ] | |||
|
|
|||
|
|
|||
| def test_encrypt_decrypt(): | |||
| def test_encapsulation(): | |||
There was a problem hiding this comment.
This isn't quite accurate. Encapsulation is a cryptographic process as a means to store encrypted keys in a specified format. I think the prior name is clear on this.
There was a problem hiding this comment.
Wait, what?
"encrypt / decrypt" is completely generic. It says nothing about what the test is testing.
And this test does in fact test encapsulation, showing that the decapsulated key is == to the encapsulated one.
Perhaps it's not an ideal name, but surely it's not less accurate than test_encrypt_decrypt?
There was a problem hiding this comment.
Well, now that you mention, the intention of this test is to test decapsulation of original capsules. Perhaps test_decapsulation_original_capsule?
There was a problem hiding this comment.
Yep, that's perfect. Also really good, if we're going to use the character names in these tests, is test_decapsulation_by_alice
No description provided.