mirror of
https://codeberg.org/scip/pcp.git
synced 2025-12-16 19:40:57 +01:00
1083 lines
46 KiB
Groff
1083 lines
46 KiB
Groff
.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14)
|
|
.\"
|
|
.\" Standard preamble:
|
|
.\" ========================================================================
|
|
.de Sp \" Vertical space (when we can't use .PP)
|
|
.if t .sp .5v
|
|
.if n .sp
|
|
..
|
|
.de Vb \" Begin verbatim text
|
|
.ft CW
|
|
.nf
|
|
.ne \\$1
|
|
..
|
|
.de Ve \" End verbatim text
|
|
.ft R
|
|
.fi
|
|
..
|
|
.\" Set up some character translations and predefined strings. \*(-- will
|
|
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
|
|
.\" double quote, and \*(R" will give a right double quote. \*(C+ will
|
|
.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
|
|
.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
|
|
.\" nothing in troff, for use with C<>.
|
|
.tr \(*W-
|
|
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
|
|
.ie n \{\
|
|
. ds -- \(*W-
|
|
. ds PI pi
|
|
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
|
|
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
|
|
. ds L" ""
|
|
. ds R" ""
|
|
. ds C` ""
|
|
. ds C' ""
|
|
'br\}
|
|
.el\{\
|
|
. ds -- \|\(em\|
|
|
. ds PI \(*p
|
|
. ds L" ``
|
|
. ds R" ''
|
|
'br\}
|
|
.\"
|
|
.\" Escape single quotes in literal strings from groff's Unicode transform.
|
|
.ie \n(.g .ds Aq \(aq
|
|
.el .ds Aq '
|
|
.\"
|
|
.\" If the F register is turned on, we'll generate index entries on stderr for
|
|
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
|
|
.\" entries marked with X<> in POD. Of course, you'll have to process the
|
|
.\" output yourself in some meaningful fashion.
|
|
.ie \nF \{\
|
|
. de IX
|
|
. tm Index:\\$1\t\\n%\t"\\$2"
|
|
..
|
|
. nr % 0
|
|
. rr F
|
|
.\}
|
|
.el \{\
|
|
. de IX
|
|
..
|
|
.\}
|
|
.\"
|
|
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
|
|
.\" Fear. Run. Save yourself. No user-serviceable parts.
|
|
. \" fudge factors for nroff and troff
|
|
.if n \{\
|
|
. ds #H 0
|
|
. ds #V .8m
|
|
. ds #F .3m
|
|
. ds #[ \f1
|
|
. ds #] \fP
|
|
.\}
|
|
.if t \{\
|
|
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
|
|
. ds #V .6m
|
|
. ds #F 0
|
|
. ds #[ \&
|
|
. ds #] \&
|
|
.\}
|
|
. \" simple accents for nroff and troff
|
|
.if n \{\
|
|
. ds ' \&
|
|
. ds ` \&
|
|
. ds ^ \&
|
|
. ds , \&
|
|
. ds ~ ~
|
|
. ds /
|
|
.\}
|
|
.if t \{\
|
|
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
|
|
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
|
|
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
|
|
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
|
|
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
|
|
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
|
|
.\}
|
|
. \" troff and (daisy-wheel) nroff accents
|
|
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
|
|
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
|
|
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
|
|
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
|
|
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
|
|
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
|
|
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
|
|
.ds ae a\h'-(\w'a'u*4/10)'e
|
|
.ds Ae A\h'-(\w'A'u*4/10)'E
|
|
. \" corrections for vroff
|
|
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
|
|
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
|
|
. \" for low resolution devices (crt and lpr)
|
|
.if \n(.H>23 .if \n(.V>19 \
|
|
\{\
|
|
. ds : e
|
|
. ds 8 ss
|
|
. ds o a
|
|
. ds d- d\h'-1'\(ga
|
|
. ds D- D\h'-1'\(hy
|
|
. ds th \o'bp'
|
|
. ds Th \o'LP'
|
|
. ds ae ae
|
|
. ds Ae AE
|
|
.\}
|
|
.rm #[ #] #H #V #F C
|
|
.\" ========================================================================
|
|
.\"
|
|
.IX Title "PCP1 1"
|
|
.TH PCP1 1 "2015-04-19" "PCP 0.2.6" "USER CONTRIBUTED DOCUMENTATION"
|
|
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
|
|
.\" way too many mistakes in technical documents.
|
|
.if n .ad l
|
|
.nh
|
|
.SH "NAME"
|
|
Pretty Curved Privacy \- File encryption using eliptic curve cryptography.
|
|
.SH "SYNOPSIS"
|
|
.IX Header "SYNOPSIS"
|
|
.Vb 6
|
|
\& Usage: pcp1 [ \-\-help | \-\-version ]
|
|
\& [ \-\-keygen | \-\-listkeys | \-\-remove\-key | \-\-edit\-key ]
|
|
\& [ \-\-export\-public | \-\-export\-secret | \-\-import ]
|
|
\& [ \-\-encrypt | \-\-decrypt ]
|
|
\& [ \-\-sign | \-\-check\-signature ]
|
|
\& [ arguments ]
|
|
\&
|
|
\& General Options:
|
|
\& \-h \-\-help Print this help message.
|
|
\& \-\-version Print program version.
|
|
\& \-D \-\-debug Enable debug output.
|
|
\& \-v \-\-verbose Enable verbose output.
|
|
\& \-V \-\-vault <vaultfile> Specify an alternate vault file.
|
|
\& \-O \-\-outfile <file> Output file. STDOUT if unspecified.
|
|
\& \-I \-\-infile <file> Input file. STDIN if unspecified.
|
|
\& \-i \-\-keyid <id> Specify a key id for various operations.
|
|
\& \-r \-\-recipient <string> Specify a recpipient, multiple allowed.
|
|
\& \-t \-\-text Print textual representation of ojects.
|
|
\&
|
|
\& Keymanagement Options:
|
|
\& \-k \-\-keygen Generate new key pair.
|
|
\& \-l \-\-listkeys List all keys stored in your vault.
|
|
\& \-R \-\-remove\-key Remove a key from the vault.
|
|
\& \-s \-\-export\-secret Export a secret key.
|
|
\& \-p \-\-export\-public Export a public key.
|
|
\& \-K \-\-import Import a secret or public key.
|
|
\& \-y \-\-export\-yaml Export all keys as YAML formatted text.
|
|
\& \-F \-\-export\-format <fmt> Specify exportformat, either \*(Aqpbp\*(Aq or \*(Aqpcp\*(Aq.
|
|
\& \*(Aqpcp\*(Aq is the default if unspecified.
|
|
\& Encryption Options:
|
|
\& \-e \-\-encrypt Asym\-Encrypt a message. If none of \-i or \-r
|
|
\& has been given, encrypt the message symetrically.
|
|
\& \-A \-\-anonymous Use anonymous sender key pair.
|
|
\& \-M \-\-add\-myself Add you primary pub key to list of recipients.
|
|
\& \-m \-\-encrypt\-sym Symetrically encrypt a message.
|
|
\& \-d \-\-decrypt Decrypt a message.
|
|
\&
|
|
\& Signature Options:
|
|
\& \-g \-\-sign Create a signature of a file.
|
|
\& \-c \-\-check\-signature Verify a signature of a file.
|
|
\& \-f \-\-sigfile <file> Write or check a detached signature file.
|
|
\&
|
|
\& Encoding Options:
|
|
\& \-z \-\-z85\-encode Armor with Z85 encoding.
|
|
\&
|
|
\& Arguments:
|
|
\& Extra arguments after options are treated as filenames or
|
|
\& recipients, depending on operation mode.
|
|
.Ve
|
|
.SH "OPTIONS"
|
|
.IX Header "OPTIONS"
|
|
.Vb 1
|
|
\& Usage: pcp1 [options]
|
|
\&
|
|
\& General Options:
|
|
\& \-V \-\-vault <vaultfile> Specify an alternate vault file.
|
|
\& The deault vault is ~/.pcpvault.
|
|
\& \-O \-\-outfile <file> Output file. If not specified, stdout
|
|
\& will be used.
|
|
\& \-I \-\-infile <file> Input file. If not specified, stdin
|
|
\& will be used.
|
|
\& \-i \-\-keyid <id> Specify a key id to import/export.
|
|
\& \-r \-\-recipient <string> Specify a recpipient, used for public
|
|
\& key export and encryption.
|
|
\& \-t \-\-text Print textual representation of some
|
|
\& item. Specify \-V to get info about a
|
|
\& vault, \-i to get info about a key id
|
|
\& installed in the vault or \-I in which
|
|
\& case it determines itself what kind of
|
|
\& file it is.
|
|
\& \-h \-\-help Print this help message.
|
|
\& \-\-version Print program version.
|
|
\& \-D \-\-debug Enable debug output.
|
|
\& \-v \-\-verbose Enable verbose output.
|
|
\&
|
|
\& Keymanagement Options:
|
|
\& \-k \-\-keygen Generate a CURVE25519 secret key. If
|
|
\& the generated key is the first one in
|
|
\& your vault, it will become the primary
|
|
\& secret key. If an output file (\-O) has
|
|
\& been specified, don\*(Aqt store the generated
|
|
\& key to the vault but export it to the
|
|
\& file instead. You will be asked for
|
|
\& an owner, mail and a passphrase. If you
|
|
\& leave the passphrase empty, the key will
|
|
\& be stored unencrypted.
|
|
\& \-l \-\-listkeys List all keys currently stored in your
|
|
\& vault. Only the key id\*(Aqs and some info
|
|
\& about the keys will be printed, not the
|
|
\& actual keys.
|
|
\& \-L \-\-listkeys\-verbose Display a more verbose key listing
|
|
\& \-l \-v including signature fingerprint, key
|
|
\& fingerprint, checksum and the like.
|
|
\& \-R \-\-remove\-key Remove a key from the vault. Requires
|
|
\& option \-i <keyid>.
|
|
\& \-s \-\-export\-secret Export a secret key. If your vault only
|
|
\& contains one secret key, this one will
|
|
\& be exported. If a key id have been
|
|
\& specified (\-i), this one will be used.
|
|
\& If there are more than one secret keys
|
|
\& in the vault and no key id has been
|
|
\& given, export the primary secret key.
|
|
\& Use \-O to export to a file.
|
|
\& \-p \-\-export\-public Export a public key. If no key id have
|
|
\& \-\-export been specified, the public part of your
|
|
\& primary secret key will be exported.
|
|
\& Use \-O to export to a file.
|
|
\& \-K \-\-import Import a key. pcp determines automatically
|
|
\& \-\-import\-key the key type and encodingg. Use \-I to import
|
|
\& from a file.
|
|
\& \-y \-\-export\-yaml Export all keys stored in your vault
|
|
\& as YAML formatted text. Use \-O to put
|
|
\& the export into a file.
|
|
\& \-F \-\-format Export the key in a particular format.
|
|
\& Currently supported: pcp, pbp, yaml,
|
|
\& perl and C.
|
|
\&
|
|
\& Encryption Options:
|
|
\& \-e \-\-encrypt Asym\-Encrypt a message. Read from stdin or
|
|
\& specified via \-I. Output will be written
|
|
\& to stdout or the file given with \-O.
|
|
\& If a keyid (\-i) has been
|
|
\& given, use that public key for encryption.
|
|
\& If one or more recipient (\-r) has been given,
|
|
\& encrypt the message for all recipients
|
|
\& asymetrically, given there are matching
|
|
\& public keys installed in the vault for them.
|
|
\& If none of \-i or \-r has been given, encrypt
|
|
\& the message symetrically. This is the same
|
|
\& as \-m (self\-encryption mode).
|
|
\& Add \-z to ascii armor the output using Z85.
|
|
\& \-A \-\-anonymous Use anonymous sender key pair instead of
|
|
\& your own primary key pair. In this mode the
|
|
\& recipient doesn\*(Aqt need to have your public
|
|
\& key.
|
|
\& \-m \-\-encrypt\-sym Sym\-Encrypt a message. Specify \-I and/or
|
|
\& \-O for input/output file. You will be asked
|
|
\& for a passphrase. No key material will
|
|
\& be used. Same as \-e without \-r and \-i.
|
|
\& \-M \-\-add\-myself Add yourself to list of recipients in asymmetric
|
|
\& encryption mode, so that you can decrypt it as
|
|
\& well.
|
|
\& \-d \-\-decrypt Decrypt a message. Read from stdin or
|
|
\& specified via \-I. Output to stdout or
|
|
\& written to the file specified via \-O.
|
|
\& The primary secret key will be used for
|
|
\& decryption, if there is no primary and
|
|
\& just one secret key in the vault, this
|
|
\& one will be used. Otherwise you\*(Aqll have
|
|
\& to specify the keyid (\-i) of the key.
|
|
\& You need to have the public key of the
|
|
\& sender installed in your vault.
|
|
\& If the input is self\-encrypted (symetrically)
|
|
\& a passphrase will be requested.
|
|
\&
|
|
\& Signature Options:
|
|
\& \-g \-\-sign Create a signature of file specified with
|
|
\& \-I (or from stdin) using your primary
|
|
\& secret key. If \-r has been given, a derived
|
|
\& secret key will be used for signing.
|
|
\& \-c \-\-check\-signature <file> Verify a signature in file <file> against
|
|
\& the file specified with \-I (or stdin).
|
|
\& The public key required for this must
|
|
\& exist in your vault file.
|
|
\& \-f \-\-sigfile <file> Write a detached signature file, which doesn\*(Aqt
|
|
\& contain the original content. Output will be
|
|
\& z85 encoded always. To verify, you need to
|
|
\& specify the original file to be verified
|
|
\& against using \-I as well (plus \-f <sigfile>).
|
|
\&
|
|
\& Encoding Options:
|
|
\& \-z \-\-z85\-encode Encode (armor) something to Z85 encoding.
|
|
\& \-a \-\-armor If used with encryption or singing operation
|
|
\& \-\-textmode encode its output. Otherwise encode a plain
|
|
\& file. Use \-I and \-O respectively, otherwise it
|
|
\& uses stdin/stdout.
|
|
\& \-Z \-\-z85\-decode Decode (dearmor) something from Z85 encoding.
|
|
\& Use \-I and \-O respectively, otherwise it
|
|
\& uses stdin/stdout
|
|
.Ve
|
|
.SH "DESCRIPTION"
|
|
.IX Header "DESCRIPTION"
|
|
\&\fBPretty Curved Privacy\fR (pcp1) is a commandline utility which can
|
|
be used to encrypt files. \fBpcp1\fR uses eliptc curve cryptography
|
|
for encryption (\s-1CURVE25519\s0 by Dan J. Bernstein). While \s-1CURVE25519\s0
|
|
is no worldwide accepted standard it hasn't been compromised by
|
|
the \s-1NSA\s0 \- which might be better, depending on your point of view.
|
|
.PP
|
|
\&\fBCaution\fR: since \s-1CURVE25519\s0 is no accepted standard, \fBpcp1\fR has
|
|
to be considered as experimental software. In fact, I wrote it just
|
|
to learn about the curve and see how it works.
|
|
.PP
|
|
Beside some differences it works like \fB\s-1GNUPG\s0\fR. So, if you already
|
|
know how to use gpg, you'll feel almost home.
|
|
.SH "QUICKSTART"
|
|
.IX Header "QUICKSTART"
|
|
Lets say, Alicia and Bobby want to exchange encrypted messages.
|
|
Here's what the've got to do.
|
|
.PP
|
|
First, both have create a secret key:
|
|
.PP
|
|
.Vb 2
|
|
\& Alicia Bobby
|
|
\& pcp1 \-k pcp1 \-k
|
|
.Ve
|
|
.PP
|
|
After entering their name, email address and a passphrase to protect
|
|
the key, it will be stored in their \fBvault file\fR (by default ~/.pcpvault).
|
|
.PP
|
|
Now, both of them have to export the public key, which has to be
|
|
imported by the other one. With \fBpcp\fR you can export the public
|
|
part of your primary key, but the better solution is to export
|
|
a derived public key especially for the recipient:
|
|
.PP
|
|
.Vb 2
|
|
\& Alicia Bobby
|
|
\& pcp1 \-p \-r Bobby \-O alicia.pub pcp1 \-p \-r Alicia \-O bobby.pub
|
|
.Ve
|
|
.PP
|
|
They've to exchange the public key somehow (which is not my
|
|
problem at the moment, use ssh, encrypted mail, whatever). Once exchanged,
|
|
they have to import it:
|
|
.PP
|
|
.Vb 2
|
|
\& Alicia Bobby
|
|
\& pcp1 \-K \-I bobby.pub pcp1 \-K \-I alicia.pub
|
|
.Ve
|
|
.PP
|
|
They will see a response as this when done:
|
|
.PP
|
|
.Vb 1
|
|
\& key 0x29A323A2C295D391 added to .pcpvault.
|
|
.Ve
|
|
.PP
|
|
Now, Alicia finally writes the secret message, encrypts it and
|
|
sends it to Bobby, who in turn decrypts it:
|
|
.PP
|
|
.Vb 4
|
|
\& Alicia Bobby
|
|
\& echo "Love you, honey" > letter
|
|
\& pcp1 \-e \-r Bobby \-I letter \-O letter.asc
|
|
\& cat letter.asc | mail bobby@foo.bar
|
|
\&
|
|
\& pcp1 \-d \-I letter.asc | less
|
|
.Ve
|
|
.PP
|
|
And that's it.
|
|
.PP
|
|
Please note the big difference to \fB\s-1GPG\s0\fR though: both Alicia
|
|
\&\s-1AND\s0 Bobby have to enter the passphrase for their secret key!
|
|
That's the way \s-1CURVE25519\s0 works: you encrypt a message using
|
|
your secret key and the recipients public key and the recipient
|
|
does the opposite, he uses his secret key and your public key
|
|
to actually decrypt the message.
|
|
.PP
|
|
Oh \- and if you're wondering why I named them Alicia and Bobby:
|
|
I was just sick of Alice and Bob. We're running NSA-free, so we're
|
|
using other sample names as well.
|
|
.SH "PCP1 KEYS"
|
|
.IX Header "PCP1 KEYS"
|
|
\&\fBpcp1\fR keys are stored in a binary file, called \fBthe vault\fR.
|
|
It's by default located in \fB~/.pcpvault\fR but you can of course
|
|
specify another location using the \fB\-V\fR option.
|
|
.PP
|
|
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.
|
|
.PP
|
|
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.
|
|
.PP
|
|
Each key can be identified using its \fBkeyid\fR which looks like this:
|
|
.PP
|
|
.Vb 1
|
|
\& 0xD49119E85266509F
|
|
.Ve
|
|
.PP
|
|
A public key exported from a secret key will have the same keyid
|
|
as the secret key.
|
|
.PP
|
|
If you just want to know details about a key or the vault, use the
|
|
\&\fB\-t\fR option.
|
|
.SH "ENCRYPTION"
|
|
.IX Header "ENCRYPTION"
|
|
There are 3 modes of encryption available in pcp1:
|
|
.IP "\fBStandard public key encryption\fR" 4
|
|
.IX Item "Standard public key encryption"
|
|
In this mode, which is the default, a public key as specified
|
|
with \fB\-i\fR or \fB\-r\fR and your primary secret key will be used
|
|
for encryption.
|
|
.Sp
|
|
Example command:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-e \-i 0x2BD734B15CE2722D \-I message.txt \-O message.asc
|
|
.Ve
|
|
.Sp
|
|
Here we didn't specify a recipient. Therefore the public
|
|
key given with \-i will be used directly.
|
|
.Sp
|
|
Another example:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-e \-r Bobby \-r McCoy \-I message.txt \-O message.asc
|
|
.Ve
|
|
.Sp
|
|
As you can see, it is also possible to encrypt a message for multiple
|
|
recipients.
|
|
.IP "\fBAonymous public key encryption\fR" 4
|
|
.IX Item "Aonymous public key encryption"
|
|
In anonymous mode a random generated keypair will be used on the
|
|
sender side. This way the recipient doesn't have to have your public
|
|
key.
|
|
.Sp
|
|
Example command:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-r \-r Bobby \-A \-I message.txt \-O message.asc
|
|
.Ve
|
|
.Sp
|
|
The public key part of the generated key pair will be included in
|
|
the output, which potentiall lessens security. Use with care and
|
|
avoid this mode when possible.
|
|
.IP "\fBSelf encryption mode\fR" 4
|
|
.IX Item "Self encryption mode"
|
|
You can also encrypt a file symetrically. No public key material
|
|
will be used in this mode.
|
|
.Sp
|
|
While this works, the security of it totally depends on the
|
|
strength of the passphrase used for encryption.
|
|
.Sp
|
|
Example command:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-e \-I message.txt \-O cipher.z85
|
|
.Ve
|
|
.Sp
|
|
As you can see we didn't specify any recipients (\-i or \-r) and therefore pcp1
|
|
operates in self mode encryption. It will ask you for a passphrase, from which
|
|
an encryption key will be derived using \fIscrypt()\fR.
|
|
.Sp
|
|
\&\s-1PCP\s0 doesn't validate the security of the passphrase.
|
|
.SH "SIGNATURES"
|
|
.IX Header "SIGNATURES"
|
|
There are 3 modes for digital signatures available on pcp1:
|
|
.IP "\fBStandard \s-1NACL\s0 binary signatures\fR" 4
|
|
.IX Item "Standard NACL binary signatures"
|
|
In this mode, which is the default, an \s-1ED25519\s0 signature will
|
|
be calculated from a \s-1BLAKE2\s0 hash of the input file content. Both
|
|
the original file content plus the signature will be written to
|
|
the output file.
|
|
.Sp
|
|
Example:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-g \-I message.txt \-O message.asc \-g
|
|
.Ve
|
|
.Sp
|
|
You will be asked for the passphrase to access your primary
|
|
secret key. The output file will be a binary file.
|
|
.IP "\fBArmored \s-1NACL\s0 signatures\fR" 4
|
|
.IX Item "Armored NACL signatures"
|
|
While this mode does the very same calculations, the output
|
|
slightly differs. The output file will be marked as a signature
|
|
file, the signature itself will be appended with its own headers
|
|
and Z85 encoded.
|
|
.Sp
|
|
Example:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-g \-I message.txt \-O message.asc \-g \-z
|
|
.Ve
|
|
.Sp
|
|
You will be asked for the passphrase to access your primary
|
|
secret key. The output file will be a text file.
|
|
.IP "\fBDetached \s-1NACL\s0 signatures\fR" 4
|
|
.IX Item "Detached NACL signatures"
|
|
In some cases you will need to have the signature separated
|
|
from the original input file, e.g. to sign download files. You
|
|
can generate detached signatures for such purposes. Still, the
|
|
signature will be calculated the same way as in standard signatures
|
|
but put out into a separate file. A detached signature file will always
|
|
be Z85 encoded.
|
|
.Sp
|
|
Example:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp1 \-g \-I message.txt \-O \-g \-\-sigfile message.sig
|
|
.Ve
|
|
.Sp
|
|
Verification by recipient:
|
|
.Sp
|
|
.Vb 1
|
|
\& pcp \-c \-f message.sig \-I message.txt
|
|
.Ve
|
|
.SH "SIGNED ENCRYPTION"
|
|
.IX Header "SIGNED ENCRYPTION"
|
|
Beside pure encryption and signatures pcp1 also supports signed
|
|
encryption. In this mode an input file will be encrypted and a
|
|
signature of the encrypted content and encrypted recipients with your primary
|
|
secret key will be appended.
|
|
.PP
|
|
The signature is encrypted as well.
|
|
.PP
|
|
Example:
|
|
.PP
|
|
.Vb 1
|
|
\& pcp1 \-e \-g \-r Bobby \-I README.txt \-O README.asc
|
|
.Ve
|
|
.PP
|
|
Please note the additional \fB\-g\fR parameter. The recipient can
|
|
decrypt and verify the so created data like this:
|
|
.PP
|
|
.Vb 1
|
|
\& pcp1 \-d \-I README.asc \-o README.txt
|
|
.Ve
|
|
.PP
|
|
If decryption works, the output file will be written. If signature
|
|
verification fails you will be informed, but the decrypted
|
|
output will be left untouched. It is up to you how to react
|
|
on an invalid signature.
|
|
.SH "ALTERNATIVE COMMANDLINES"
|
|
.IX Header "ALTERNATIVE COMMANDLINES"
|
|
You can save typing if you supply additional arguments to
|
|
pcp after commandline options. Such arguments are treated
|
|
as filenames or recipients, depending what options you already
|
|
specified.
|
|
.PP
|
|
Here is a list of commandlines and their possible alternatives:
|
|
.PP
|
|
.Vb 1
|
|
\& ORIGINAL ALTERNATIVE DESCRIPTION
|
|
\&
|
|
\& pcp \-e \-I message \-r Bob pcp \-e \-r Bob message use \*(Aqmessage\*(Aq as inputfile.
|
|
\& pcp \-e \-I message Bob use \*(AqBob\*(Aq as recipient,
|
|
\& multiple recipients supported.
|
|
\&
|
|
\& pcp \-d \-I crypted pcp \-d crypted use \*(Aqcrypted\*(Aq as inputfile.
|
|
\&
|
|
\& pcp \-g \-I message pcp \-g message use \*(Aqmessage\*(Aq as inputfile.
|
|
\&
|
|
\& pcp \-g \-I msg \-O sig pcp \-g \-I msg sig use \*(Aqsig\*(Aq as outputfile.
|
|
\&
|
|
\& pcp \-p \-O key.pcp pcp \-p key.pcp use \*(Aqkey.pcp\*(Aq as outputfile.
|
|
\&
|
|
\& pcp \-p \-O key.pcp \-r Bob pcp \-p \-O key.pcp Bob use \*(AqBob\*(Aq as recipient.
|
|
\&
|
|
\& pcp \-s \-O key.pcp pcp \-s key.pcp use \*(Aqkey.pcp\*(Aq as outputfile.
|
|
\&
|
|
\& pcp \-s \-O key.pcp \-r Bob pcp \-s \-O key.pcp Bob use \*(AqBob\*(Aq as recipient.
|
|
\&
|
|
\& pcp \-K \-I alice.pcp pcp \-K alice.pcp use \*(Aqalice.pcp\*(Aq as keyfile.
|
|
.Ve
|
|
.SH "ENVIRONMENT VARIABLES"
|
|
.IX Header "ENVIRONMENT VARIABLES"
|
|
pcp respects the following environment variables:
|
|
.IP "\fB\s-1PCP_VAULT\s0\fR" 4
|
|
.IX Item "PCP_VAULT"
|
|
Use an alternative vaultfile. The default is \fB~/.pcpvault\fR and
|
|
can be overridden with the \fB\-V\fR commandline option. If \s-1PCP_VAULT\s0
|
|
is set, this one will be used instead.
|
|
.IP "\fB\s-1PCP_DEBUG\s0\fR" 4
|
|
.IX Item "PCP_DEBUG"
|
|
Enable debugging output, where supported. Same as \fB\-D\fR.
|
|
.SH "EXIT STATUS"
|
|
.IX Header "EXIT STATUS"
|
|
Pcp may return one of several error codes if it encounters problems.
|
|
.IP "0 No problems occurred." 4
|
|
.IX Item "0 No problems occurred."
|
|
.PD 0
|
|
.IP "1 Generic error code." 4
|
|
.IX Item "1 Generic error code."
|
|
.PD
|
|
.SH "FILES"
|
|
.IX Header "FILES"
|
|
.IP "\fB~/.pcpvault\fR" 4
|
|
.IX Item "~/.pcpvault"
|
|
Default vault file where all keys are stored.
|
|
.SH "EXPERIMENTAL STATUS"
|
|
.IX Header "EXPERIMENTAL STATUS"
|
|
Currently there are a couple of problems which are currently
|
|
unsolved or in the process to be solved.
|
|
.IP "\fBNo secure native key exchange for store-and-forward systems\fR" 4
|
|
.IX Item "No secure native key exchange for store-and-forward systems"
|
|
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 \fBCurveCP\fR which guarantees a
|
|
secure key exchange. But CurveCP cannot be used offline.
|
|
.Sp
|
|
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 \s-1AND\s0 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.
|
|
.IP "\fBCurve25519 not widely adopted\fR" 4
|
|
.IX Item "Curve25519 not widely adopted"
|
|
At the time of this writing the \s-1ECC\s0 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
|
|
\&\s-1ECC\s0 algorithms.
|
|
.Sp
|
|
While I, as the author of pcp1 totally trust D.J.Bernstein, this
|
|
may not be the case for you.
|
|
.Sp
|
|
In short, I'd suggest not to use it on critical systems yet.
|
|
.SH "INTERNALS"
|
|
.IX Header "INTERNALS"
|
|
.SS "\s-1VAULT\s0 \s-1FORMAT\s0"
|
|
.IX Subsection "VAULT FORMAT"
|
|
The vault file contains all public and secret keys. It's a portable
|
|
binary file.
|
|
.PP
|
|
The file starts with a header:
|
|
.PP
|
|
.Vb 9
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | File ID | 1 | Vault Identifier 0xC4 |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Version | 4 | Big endian, version |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Checksum | 32 | SHA256 Checksum |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
The checksum is a checksum of all keys.
|
|
.PP
|
|
The header is followed by the keys. Each key is preceded by a
|
|
key header which looks like this:
|
|
.PP
|
|
.Vb 11
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Type | 1 | Key type (S,P,M) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Size | 4 | Big endian, keysize |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Version | 4 | Big endian, keyversion |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Checksum | 32 | SHA256 Key Checksum |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
Type can be one of:
|
|
.PP
|
|
.Vb 3
|
|
\& PCP_KEY_TYPE_MAINSECRET 0x01
|
|
\& PCP_KEY_TYPE_SECRET 0x02
|
|
\& PCP_KEY_TYPE_PUBLIC 0x03
|
|
.Ve
|
|
.PP
|
|
The key header is followed by the actual key, see below.
|
|
.SS "\s-1SECRET\s0 \s-1KEY\s0 \s-1FORMAT\s0"
|
|
.IX Subsection "SECRET KEY FORMAT"
|
|
A secret key is a binary structure with the following format:
|
|
.PP
|
|
.Vb 10
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Public | 32 | Curve25519 Public Key Part |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Secret | 32 | Curve25519 Secret Key Unencrypted|
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | ED25519 Pub | 32 | ED25519 Public Key Part |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | ED25519 Sec | 64 | ED25519 Secret Key Unencrypted |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Nonce | 24 | Nonce for secret key encryption |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Encrypted | 48 | Encrypted Curve25519 Secret Key |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Owner | 255 | String, Name of Owner |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Mail | 255 | String, Email Address |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | ID | 17 | String, Key ID |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Ctime | 4 | Creation time, sec since epoch |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Version | 4 | Key version |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Serial | 4 | Serial Number |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Type | 1 | Key Type |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
Some notes:
|
|
.PP
|
|
The secret key fields will be filled with random data if the
|
|
key is encrypted. The first byte of it will be set to 0 in that
|
|
case.
|
|
.PP
|
|
The key id is a computed \s-1JEN\s0 Hash of the secret and public
|
|
key concatenated, put into hex, as a string.
|
|
.PP
|
|
The key version is a static value, currently 0x2. If the key
|
|
format changes in the future, this version number will be
|
|
increased to distinguish old from new keys.
|
|
.PP
|
|
Exported keys will be encoded in Z85 encoding. When such an
|
|
exported key is imported, only the actual Z85 encoded data
|
|
will be used. Header lines and lines starting with whitespace
|
|
will be ignored. They are only there for convenience.
|
|
.PP
|
|
Key generation works like this:
|
|
.IP "\(bu" 4
|
|
Generate a random seed (32 bytes).
|
|
.IP "\(bu" 4
|
|
Generate a \s-1ED25519\s0 sigining keypair from that seed.
|
|
.IP "\(bu" 4
|
|
Generate a random seed (32 bytes).
|
|
.IP "\(bu" 4
|
|
Generate a Curve25519 encryption keypair from that seed.
|
|
.PP
|
|
So, while both secrets are stored in the sam \s-1PCP\s0 key, they
|
|
are otherwise unrelated. If one of them leaks, the other
|
|
cannot be recalculated from it.
|
|
.PP
|
|
Take a look at the function \fB\f(BIpcp_keypairs()\fB\fR for details.
|
|
.SS "\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0"
|
|
.IX Subsection "ENCRYPTED OUTPUT FORMAT"
|
|
The encryption protocol used by \s-1PCP\s0 uses mostly standard
|
|
libsodium facilities with the exception that \s-1PCP\s0 uses counter
|
|
mode (CTR-Mode) for stream encryption.
|
|
.PP
|
|
.Vb 1
|
|
\& Detailed description:
|
|
.Ve
|
|
.IP "generate a random ephemeral 32 byte key \fBS\fR" 4
|
|
.IX Item "generate a random ephemeral 32 byte key S"
|
|
.PD 0
|
|
.IP "encrypt it asymetrically for each recipient using a unique nonce (\fBR\fR)" 4
|
|
.IX Item "encrypt it asymetrically for each recipient using a unique nonce (R)"
|
|
.IP "encrypt the input file 32k blockwise using the ephemeral key" 4
|
|
.IX Item "encrypt the input file 32k blockwise using the ephemeral key"
|
|
.RS 4
|
|
.IP "for each input block with a size of 32k bytes:" 4
|
|
.IX Item "for each input block with a size of 32k bytes:"
|
|
.IP "generate a random nonce \fBN\fR" 4
|
|
.IX Item "generate a random nonce N"
|
|
.IP "put the current counter size into the first byte of the nonce" 4
|
|
.IX Item "put the current counter size into the first byte of the nonce"
|
|
.IP "put the current counter (starting with 1) into the following byte(s), if larger than 1 byte, in big endian mode" 4
|
|
.IX Item "put the current counter (starting with 1) into the following byte(s), if larger than 1 byte, in big endian mode"
|
|
.IP "encrypt the 32k block using \fB\f(BIcrypto_secretbox()\fB\fR with the nonce \fBN\fR and the ephemeral key \fBS\fR" 4
|
|
.IX Item "encrypt the 32k block using crypto_secretbox() with the nonce N and the ephemeral key S"
|
|
.RE
|
|
.RS 4
|
|
.RE
|
|
.PD
|
|
.PP
|
|
Symetric encryption works the very same without the recipient stuff.
|
|
.PP
|
|
Formal format description, asymetric encrypted files:
|
|
.PP
|
|
.Vb 10
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Type | 1 | Filetype, 5=ASYM, 23=SYM, 6=ANON |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Anon PUB * | 32 | anon pubkey, only used with type 6 |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Len R * | 4 | Number of recipients (*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Recipients *| R*72 | C(recipient)|C(recipient)... (*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Encrypted | ~ | The actual encrypted data |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
*) not included when doing symetric encryption.
|
|
.PP
|
|
Recipient field format:
|
|
.PP
|
|
.Vb 7
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Nonce | 24 | Random Nonce, one per R |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Cipher | 48 | S encrypted with PK or R |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
R is generated using \fB\f(BIcrypto_box()\fB\fR with the senders
|
|
secret key, the recipients public key and a random nonce.
|
|
.PP
|
|
Pseudocode:
|
|
.PP
|
|
.Vb 5
|
|
\& R = foreach P: N | crypto_box(S, N, P, SK)
|
|
\& L = len(R)
|
|
\& T = 5
|
|
\& write (T | L | R)
|
|
\& foreach I: write (N | crypto_secret_box(I, N, S))
|
|
.Ve
|
|
.PP
|
|
where P is the public key of a recipient, \s-1SK\s0 is the senders
|
|
secret key, R is the recipient list, L is the number of recipients,
|
|
T is the filetype header, I is a block of input with a size
|
|
of 32k, N is a nonce (new per block) and S the symmetric key.
|
|
.PP
|
|
If using anonymous encryption, the sender generates a ephemeral
|
|
key pair, uses the secret part of it to generate R. The public
|
|
part will be included with the output (right after the file type.
|
|
In this mode a recipient is not required to have the public key
|
|
of the sender.
|
|
.PP
|
|
The encrypted output maybe Z85 encoded. In this case the Z85
|
|
encoding will be done blockwise with blocks of 16k bytes. The
|
|
decoded content inside will be as described above.
|
|
.SS "\s-1SIGNATURE\s0 \s-1FORMAT\s0"
|
|
.IX Subsection "SIGNATURE FORMAT"
|
|
There are different signature formats. Standard binary \s-1NACL\s0
|
|
signatures have the following format:
|
|
.PP
|
|
.Vb 11
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Content | ~ | Original file content |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | \ennacl\- | 6 | Offset separator |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Hash | 64 | BLAKE2 hash of the content |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Signature | 64 | ED25519 signature of BLAKE2 Hash |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
The actual signature is not a signature over the whole content
|
|
of an input file but of a \s-1BLAKE2\s0 hash of the content.
|
|
.PP
|
|
Pseudo code:
|
|
.PP
|
|
.Vb 2
|
|
\& H = crypto_generichash(C)
|
|
\& C | O | H | crypto_sign(H, S)
|
|
.Ve
|
|
.PP
|
|
where C is the message (content), H is the blake2 hash,
|
|
O is the offset separator and S is the secret signing key
|
|
of the sender.
|
|
.PP
|
|
Armored signatures have the following format:
|
|
.PP
|
|
.Vb 2
|
|
\& \-\-\-\-\- BEGIN ED25519 SIGNED MESSAGE \-\-\-\-\-
|
|
\& Hash: Blake2
|
|
\&
|
|
\& MESSAGE
|
|
\&
|
|
\& \-\-\-\-\- BEGIN ED25519 SIGNATURE \-\-\-\-\-
|
|
\& Version: PCP v0.2.0
|
|
\&
|
|
\& 195j%\-^/G[cVo4dSk7hU@D>NT\-1rBJ]VbJ678H4I!%@\-)bzi>zOba5$KSgz7b@R]A0!kL$m
|
|
\& MTQ\-1DW(e1mma(<jH=QGA(VudgAMXaKF5AGo65Zx7\-5fuMZt&:6IL:n2N{KMto*KQ$:J+]d
|
|
\& dp1{3}Ju*M&+Vk7=:a=J0}B
|
|
\& \-\-\-\-\-\- END ED25519 SIGNATURE \-\-\-\-\-\-
|
|
.Ve
|
|
.PP
|
|
The Z85 encoded signature at the end contains the same signature
|
|
contents as the binary signature outlined above (hash+sig).
|
|
.SS "\s-1SIGNED\s0 \s-1ENCRYPTION\s0 \s-1FORMAT\s0"
|
|
.IX Subsection "SIGNED ENCRYPTION FORMAT"
|
|
Signed encrypted files are in binary form only. The first part is
|
|
the standard encrypted file as described in \fB\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0\fR
|
|
followed by the binary encrypted signature described in \fB\s-1SIGNATURE\s0 \s-1FORMAT\s0\fR
|
|
without the offset separator.
|
|
.PP
|
|
However, not only the hash of the file content will be signed but the
|
|
recipient list described in \fB\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0\fR as well. A
|
|
valid recipient is therefore not able to re-encrypt the decrypted
|
|
message, append the original signature and send it to other recipients.
|
|
The signature would not match since the recipient list differs and
|
|
so recipients know that the signature is forged.
|
|
.PP
|
|
Formal file description of sign+encrypt format:
|
|
.PP
|
|
.Vb 10
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Type | 1 | Filetype, 5=ASYM, 23=SYM |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Len R | 4 | Number of recipients (*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Recipients | R*72 | C(recipient)|C(recipient)... (*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Encrypted | ~ | The actual encrypted data |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Signature | ~ | Encrypted signature(*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
As usual the encrypted signature consists of a nonce and the
|
|
actual cipher, which is computed symmetrically (see above)
|
|
from the following clear signature.
|
|
.PP
|
|
Before encryption the signature format is:
|
|
.PP
|
|
.Vb 7
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Field Size Description |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Hash | 64 | BLAKE2 hash of content+R (*) |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
\& | Signature | 64 | ED25519 signature of BLAKE2 Hash |
|
|
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
|
.Ve
|
|
.PP
|
|
where R is: C(recipient)|C(recipient)... (see \fB\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0\fR).
|
|
.PP
|
|
Pseudocode:
|
|
.PP
|
|
.Vb 1
|
|
\& N | crypto_secret_box( crypto_sign( crypto_generichash( M + R, SK ) ), N, S)
|
|
.Ve
|
|
.PP
|
|
where N is the nonce, M the message, R the recipient list, \s-1SK\s0 is the senders
|
|
secret signing key and S the symmetric key.
|
|
.SS "Z85 \s-1ENCODING\s0"
|
|
.IX Subsection "Z85 ENCODING"
|
|
\&\fBpcp1\fR uses Z85 to encode binary data (if requested with \-z) such
|
|
as encrypted data, exported keys or armored signatures.
|
|
.PP
|
|
Encoded data is always enclosed by a header and a footer and may have any number
|
|
of comments. Example:
|
|
.PP
|
|
.Vb 5
|
|
\& \-\-\-\-\- PCP ENCRYPTED FILE \-\-\-\-\-
|
|
\& Version: PCP 0.2.1
|
|
\& 246ge]+yn={<I&&Z%(pm[09lc5[dx4TZALi/6cjVe)Kx5S}7>}]Xi3*N3Xx34Y^0rz:r.5j
|
|
\& v#6Sh/m3XKwy?VlA+h8ks]9:kVj{D[fd7]NA]T\-(ne+xo!W5X5\-gIUWqM
|
|
\& \-\-\-\-\- END PCP ENCRYPTED FILE \-\-\-\-\-
|
|
.Ve
|
|
.PP
|
|
However, the parser tries to be as tolerant as possible. It also accepts
|
|
Z85 encoded data without headers or without newlines, empty lines or lines
|
|
containing a space are ignored as well as comments. Empty comments are not
|
|
allowed.
|
|
.PP
|
|
\fIZ85 \s-1PADDING\s0\fR
|
|
.IX Subsection "Z85 PADDING"
|
|
.PP
|
|
\&\s-1PCP\s0 uses a custom padding scheme. Z85 input data size must be a multiple
|
|
of 4. To fulfill this requirement, \s-1PCP\s0 padds the input with zeros as
|
|
neccessary. To tell the decoder if padding took place and how much zeros
|
|
have been added, \s-1PCP\s0 adds another 4 bytes after each Z85 encoded block,
|
|
from the last one which contains the number of zeros used for padding,
|
|
even if the input hasn't been padded.
|
|
.PP
|
|
\fIZ85 \s-1BACKGROUND\s0\fR
|
|
.IX Subsection "Z85 BACKGROUND"
|
|
.PP
|
|
The Z85 encoding format is described here: \fBhttp://rfc.zeromq.org/spec:32\fR.
|
|
It's part of ZeroMQ (\fBhttp://zeromq.org\fR). Z85 is based on \s-1ASCII85\s0 with
|
|
a couple of modifications (portability, readability etc).
|
|
.PP
|
|
To fulfil the requirements of the ZeroMQ Z85 functions, \fBpcp1\fR
|
|
does some additional preparations of raw input before actually doing the
|
|
encoding, since the input for \fIzmq_z85_encode()\fR must be divisible by 4. Therefore
|
|
we pad the input with zeroes and remove them after decoding.
|
|
.PP
|
|
\&\fBTrying to use another tool to decode an Z85 encoded string produced
|
|
by z85, might not work therefore, unless the tool takes the padding scheme
|
|
outlined above into account\fR.
|
|
.PP
|
|
Z85 encoding and decoding can be used separately as well to work with
|
|
files. Examples:
|
|
.PP
|
|
Encode some file to Z85 encoding:
|
|
.PP
|
|
pcp1 \-z \-I file \-O file.z85
|
|
.PP
|
|
Reverse the process:
|
|
.PP
|
|
pcp1 \-Z \-I file.z85 \-O file
|
|
.SS "\s-1PBP\s0 \s-1COMPATIBILITY\s0"
|
|
.IX Subsection "PBP COMPATIBILITY"
|
|
\&\s-1PCP\s0 tries to be fully compatible with \s-1PBP\s0 (https://github.com/stef/pbp). Encrypted
|
|
files and signatures \- at least their binary versions \- should be exchangable. However,
|
|
this is a work in progress and might not work under all circumstances. Also there's currently
|
|
no shared key format between pbp and pcp. However, it is possible to export and
|
|
import pbp keys from/to pcp.
|
|
.SH "COPYRIGHT"
|
|
.IX Header "COPYRIGHT"
|
|
Copyright (c) 2013\-2015 by T.v.Dein <tom \s-1AT\s0 vondein \s-1DOT\s0 org>
|
|
.SH "ADDITIONAL COPYRIGHTS"
|
|
.IX Header "ADDITIONAL COPYRIGHTS"
|
|
.IP "\fBZeroMQ Z85 encoding routine\fR" 4
|
|
.IX Item "ZeroMQ Z85 encoding routine"
|
|
.Vb 5
|
|
\& Copyright (c) 2007\-2013 iMatix Corporation
|
|
\& Copyright (c) 2009\-2011 250bpm s.r.o.
|
|
\& Copyright (c) 2010\-2011 Miru Limited
|
|
\& Copyright (c) 2011 VMware, Inc.
|
|
\& Copyright (c) 2012 Spotify AB
|
|
.Ve
|
|
.IP "\fBTarsnap readpass helpers\fR" 4
|
|
.IX Item "Tarsnap readpass helpers"
|
|
.Vb 1
|
|
\& Copyright 2009 Colin Percival
|
|
.Ve
|
|
.IP "\fB\f(BIjen_hash()\fB hash algorithm\fR" 4
|
|
.IX Item "jen_hash() hash algorithm"
|
|
.Vb 1
|
|
\& Bob Jenkins, Public Domain.
|
|
.Ve
|
|
.IP "\fB\s-1UTHASH\s0 hashing macros\fR" 4
|
|
.IX Item "UTHASH hashing macros"
|
|
.Vb 1
|
|
\& Copyright (c) 2003\-2013, Troy D. Hanson
|
|
.Ve
|
|
.IP "\fBRandom art image from OpenSSH keygen\fR" 4
|
|
.IX Item "Random art image from OpenSSH keygen"
|
|
.Vb 1
|
|
\& Copyright (c) 2000, 2001 Markus Friedl. All rights reserved.
|
|
\&
|
|
\& Comitted by Alexander von Gernler in rev 1.7.
|
|
.Ve
|
|
.PP
|
|
Every incorporated source code is opensource and licensed
|
|
under the \fB\s-1GPL\s0\fR as well.
|
|
.SH "AUTHORS"
|
|
.IX Header "AUTHORS"
|
|
\&\fIT.v.Dein <tom \s-1AT\s0 vondein \s-1DOT\s0 org\fR>
|
|
.SH "LICENSE"
|
|
.IX Header "LICENSE"
|
|
Licensed under the \s-1GNU\s0 \s-1GENERAL\s0 \s-1PUBLIC\s0 \s-1LICENSE\s0 version 3.
|
|
.SH "HOME"
|
|
.IX Header "HOME"
|
|
The homepage of Pretty Curved Privacy can be found on
|
|
http://www.daemon.de/PrettyCurvedPrivacy. The source is
|
|
on Github: https://github.com/TLINDEN/pcp
|