Closed hardbyte closed 8 years ago
I propose we serialize to a JWK:
{
"kty": "PAI",
"key_ops": ["encrypt"],
"n": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlk",
"kid": "Paillier public key generated by pheutil on 2016-01-07",
"g": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlo"
}
The private key needs to contain the public key. Another command for the tool could be to extract the public key (similar to openssl rsa -in private.pem -outform PEM -pubout -out public.pem
)
{
"kty": "PAI",
"lambda": "mI0ZcVCsErvAmcm5cFCyhw3ZEETBTO1_0IxFFJIMKKQ",
"pub": {
"kty": "PAI",
"key_ops": ["encrypt"],
"n": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlk",
"kid": "Paillier public key generated by pheutil on 2016-01-07",
"g": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlo"
},
"key_ops": ["decrypt"],
"kid": "Paillier private key generated by pheutil on 2016-01-07",
"mu": "YPRTV75i7AloPJwZY0CQncg6e-o-H9Osbrb4RhLt0Gw"
}
g
of the PublicKey is always chosen to be g=n+1
. This allows for optimisations without loss of security and therefore n
fully describes a PublicKey. If you want to support more general PublicKeys with arbitrary values for g
then we probably should add an identifier for the special case for g to the 'alg' field.alg
attribute and drop g
for now. How about "PAI-GN1"
kid
value. I'll increase the resolution of the datestamp included in the default message too.I'm commenting to both issue #6 and #7 here because I'm not sure where to write what.
In openssl, they use the command genpkey
to generate a private key, followed by '-algorithm {alg_name}' ...
Then they use the commands openssl rsautl -encrypt
or openssl rsautl -decrypt
to use the rsa utilities functions as encrypt, decrypt...
So for the generation of the private key, we could indeed be a bit more explicit but it would be nice not to have a too long command, genpkey
might be a good one.
extract
makes sense to extract the public key from the private key. Or following openssl, using the tag `pubout'.
kty
. Seeing the example in the RFC, they mention RSA, EC... which specifies a type of encryption, i.e which mathematical problem the encryption is relying on, not the way to use it and its additional properties. While setting kty
to PAI
could be too restrictive as Paillier is one algorithm of a more general type of encryption, maybe we could put DAJ
for Damgard Jurik as Paillier is one of its subset. "phe" would more describe an additional property of the encryption, not a type of encryption. But the utility file where the encryption and decryption methods should be referred as paiutil
or dajutil
instead of pheutil
to be consistent.alg
we could specifies that we are using Paillier algorithm, with a precise way to choose g. PAI-GN1
is quite nice :)kid
, should we also introduce some randomness in case two people create a key at the same time? And does it need to include a text?I'm happy with kid
including a timestamp including seconds. I don't think more randomness is necessary - it isn't a hash of the key or used for anything other that being a human readable identifier. More like the comment at the end of an openssh public key.
Current output:
$ python -m phe.command_line genpkey --keysize 256 -
Generating a paillier keypair with keysize of 256
Keys generated
{"lambda": "lJRWztvgs-Y1sdxn8ViF-CDX7JSK9grSyOeoRe_FllA", "mu": "HNQ8rxj2OYIZWF4dnRce3Y5ybAX2baj9IG2RwASJ6qI", "kty": "PAI", "pub": {"kid": "Paillier public key generated by pheutil on 2016-01-08 16:11:20", "n": "lJRWztvgs-Y1sdxn8ViF-bOsIYkOmdt1E9YAfwyCR7k", "alg": "PAI-GN1", "kty": "PAI", "key_ops": ["encrypt"]}, "kid": "Paillier private key generated by pheutil on 2016-01-08 16:11:20", "key_ops": ["decrypt"]}
Private key written to <stdout>
Only the json is printed to stdout, logging is to stderr. A better way to format for github:
$ python -m phe.command_line genpkey --keysize 256 - | python -m json.tool
Generating a paillier keypair with keysize of 256
Keys generated
Private key written to <stdout>
{
"mu": "QwsTCSVOeyLGJYvGEHwW-9i6n8UR999hOFkPzAExguY",
"kid": "Paillier private key generated by pheutil on 2016-01-08 16:12:57",
"lambda": "iNpGYHCFIpjP1cSm7Ul05jXFsSO5YNpykNfSHke23JA",
"key_ops": [
"decrypt"
],
"kty": "PAI",
"pub": {
"key_ops": [
"encrypt"
],
"alg": "PAI-GN1",
"n": "iNpGYHCFIpjP1cSm7Ul057l8OjcvaYnQMC3mKWGVIlM",
"kty": "PAI",
"kid": "Paillier public key generated by pheutil on 2016-01-08 16:12:57"
}
}
:+1: for using "kty": "DAJ", "alg": "PAI-GN1"
.
@felixlawrence or @djvis care to weigh in?
The docs say that
"kty" values should either be registered in the IANA "JSON Web Key Types" registry established by [JWA] or be a value that contains a Collision- Resistant Name.
As noted above, the whitelist of acceptable names, as of last year, comprised RSA
, EC
and oct
.
Is "DAJ" considered 'collision-resistant'? Does this matter? Would it be a sin to be more verbose - although it looks like no-one else is doing that?
I don't really have an opinion on this because I lack the knowledge and imagination to see how these choices could make life dramatically easier or more difficult for us or for others trying to follow the standard in the future!
Actually the only useful thing I'd add here is that there should maybe be some sort of versioning in here so that we could potentially be forwards-compatible if anything ever needs to change?
Thanks all for the ideas and feedback.
To aide testing integration between python-paillier and javallier, add a command line program to:
Initially use a standard encoding scheme.