=head1 PCP1 KEYS B keys are stored in a binary file, called B. It's by default located in B<~/.pcpvault> but you can of course specify another location using the B<-V> option. There are two kinds of keys: secret and public keys. In reality a secret key always includes its public key. Both types of keys can be exported to files and transfered to other people who can then import them. You should usually only do this with public keys though. There is a primary secret key which will always used for operations when no keyid has been specified. However, you may have as many secret keys in your vault as you like. Each key can be identified using its B which looks like this: 0xD49119E85266509F A public key exported from a secret key will have the same keyid as the secret key. When using for encryption, the keyid will be added to the message so that the receiver knows who was the sender of the message (B). If you just want to know details about a key or the vault, use the B<-t> option. =head2 Derived Public Keys In the real world you would not use your primary key to encrypt messages, because this would require to send the public key part to your recipient in one way or another. The much better and more secure way is to use a B: Such a key will be dynamically generated from a hash of your primary secret key and the recipient (an email address, name or key id). The public part of this dynamic key will be exported and sent to the recipient. A public key generated this way will only be usable by the recipient (and yourself) and each recipient will have a different public key from you (and vice versa). =head1 ENCRYPTION There are 3 modi for encryption available in pcp1: =over =item B In this mode, which is the default, a public key as specified with B<-i> and the primary secret key will be used for encryption. The public key in question maybe a derived public key, which is transparent for the sender however. If you don't use derived keys, you will have to transfer the public key part of your primary keypair to the recipient, which is considered insecure if the transfer channel itself uses untrusted transports or if the transferred public key ends up on a public system (a shared server, a workstation at your employer or the like). You should avoid this encryption mode in such cases and use derived keys instead. Example command: pcp1 -e -i 0x2BD734B15CE2722D -I message.txt -O cipher.z85 Here we didn't specify a recipient. Therefore the public key given with -i will be used directly. =item B Derived keys will be generated dynamically at runtime (see B above). Therefore an exported derived public key is unique for the sender AND recipient. This mode can be considered the most secure. If such a key gets lost (or into the wrong hands), only this specific communication channel will be compromised. Example command: pcp1 -e -r bobby@local -I message.txt -O cipher.z85 We specified a recipient. pcp1 searches the vault for a matching public key and generates a derived keypair for encryption. You need to have a public key installed from the recipient anyway, it won't work without one. You may also specify a key id (-i) as well to make sure, the right key will be used for derivation. =item B Pretty Curved Privacy doesn't provide symetric file encryption. However there are cases when you need to encrypt a file just for yourself. In such a case the file will be encrypted using the public key part of your primary secret key and the secret key itself (thanks to the wonders of ECC this works like a charm). The file can be decrypted using the primary key pair. While this works, the security of it totally depends on the strength of your password, especially if the primary secret used for this kind of encryption is stored in a vault on the same system. Example command: pcp1 -e -I message.txt -O cipher.z85 As you can see we didn't specify -i or -r and therefore pcp1 tries to use the primary keypair for encryption. =back =head1 VULNERABILITIES Currently there are a couple of problems which are not addressed. These are usually protocol problems, which are not caused by pcp1. =over =item B Pretty Curved Privacy is a store-and-forward system, it works on files and can't use any cool key exchange protocols therefore. For example there would be B which guarantees a secure key exchange. But CurveCP cannot be used offline. Users have to find other means to exchange keys. That's a pity since with Curve25519 you can't just publish your public key to some key server because in order to encrypt a message, both the recipient AND the sender need to have the public key of each other. It would be possible to publish public keys, and attach the senders public key to the encrypted message, but I'm not sure if such an aproach would be secure enough. =item B At the time of this writing the ECC algorithm Curve25519 is only rarely used, in most cases by experimental software (such as Pretty Curved Privacy). As far as I know there haven't been done the kind of exessive crypto analysis as with other ECC algorithms. While I, as the author of pcp1 totally trust D.J.Bernstein, this may not be the case for you. In short, I'd suggest not to use it on critical systems yet. =back =head1 INTERNALS FIXME. =head1 Z85 ENCODING B uses Z85 to encode exported keys and encrypted messages. Therefore it includes a Z85 utility mode: B can be used to encode and decode strings to Z85 encoding. The option B<-z> encodes B Z85, the option B<-Z> does the opposite and decodes B Z85. If no input file have been specified using B<-I>, B expects the input to come from B, otherwise it reads the contents of B. Encoded or decoded output will be written to B unless an output file has been specified using the option B<-O>. =head2 Z85 EXAMPLES To encode a given file to Z85 and write the output to another: pcp1 -z myfile.bin > myfile.z85 To decode the file created above and restore the original: pcp1 -Z -d myfile.z85 > myfile.bin To encode something from stdin to Z85: ps axuw | pcp1 -z > pslist.z85 To decode the above and print to stdout: pcp1 -Z -d pslist.z85 =head2 Z85 BACKGROUND The Z85 encoding format is described here: B. It's part of ZeroMQ (B). Z85 is based on ASCII85 with a couple of modifications (portability, readability etc). To fulfil the requirements of the ZeroMQ Z85 functions, B does some additional preparations of raw input before actually doing the encoding, since the input for zmq_z85_encode() must be divisible by 4: Expand the input so that the resulting size is divisible by 4. Fill the added bytes with zeroes. Prepend the input with a one byte value which holds the number of zeroes added in the previous step. Example: Raw input: hello\0 Here, the input size is 6, which is insufficient, therefore it has to be expanded to be 8. After the process the input looks like this: 1hello\0\0 So, we padded the input with 1 zero (makes 7 bytes) and preprended it with the value 1 (the number of zeros added): makes 8 bytes total. After decoding Z85 input the process will be reversed. B.