Command line binary

[hardbyte]

To aide testing integration between python-paillier and javallier, add a command line program to:

• generate and serialize key pairs (of different key sizes)
• encrypt and serialize given a public key and a plaintext number
• decrypt given a private key and the ciphertext
• add two encrypted numbers together
• add an encrypted number to a plaintext number
• multiply an encrypted number to a plaintext number

Initially use a standard encoding scheme.

[hardbyte]

I propose we serialize to a JWK:

Public Key

{
  "kty": "PAI", 
  "key_ops": ["encrypt"], 
  "n": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlk", 
  "kid": "Paillier public key generated by pheutil on 2016-01-07", 
  "g": "mI0ZcVCsErvAmcm5cFCyiKBdFUAxEs5VYsn9R0Jknlo"
}

Private Key

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"
}

[wilko77]

• Maybe change "PAI" in the "kty" field to "PHE" to be more consistent.
• In Javallier, the generator 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.
• As I understand the description of the key ID 'kid' parameter, these values should be different for different keys, unless those keys have different 'kty' values. In your current form, all keys generated on the same day will have the same value for 'kid'.

[hardbyte]

• We chose phe to originally stand for Partially Homomorphic Encryption library - implementations other than paillier never landed in this library. See Module name #5 as I'd like to rename the library interface. Is PHE used within the javallier library?
• Fair enough. I think we should both include an alg attribute and drop g for now. How about "PAI-GN1"
• I added a parameter to the tool so users can set their own kid value. I'll increase the resolution of the datestamp included in the default message too.

[gusmith]

I'm commenting to both issue #6 and #7 here because I'm not sure where to write what.

About the command line library:

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

Answering the previous comments:

• I agree with Brian: we should not use "phe" in 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.
• Then in alg we could specifies that we are using Paillier algorithm, with a precise way to choose g. PAI-GN1 is quite nice :)
• for the 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?

[hardbyte]

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.

[hardbyte]

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"
    }
}

[hardbyte]

👍 for using "kty": "DAJ", "alg": "PAI-GN1".

@felixlawrence or @djvis care to weigh in?

[felixlawrence]

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!

[felixlawrence]

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?

[hardbyte]

Thanks all for the ideas and feedback.