mirror of
https://codeberg.org/scip/pcp.git
synced 2025-12-17 03:50:57 +01:00
fix POD
This commit is contained in:
85
man/pcp1.1
85
man/pcp1.1
@@ -1,4 +1,4 @@
|
||||
.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.16)
|
||||
.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
|
||||
.\"
|
||||
.\" Standard preamble:
|
||||
.\" ========================================================================
|
||||
@@ -38,6 +38,8 @@
|
||||
. ds PI \(*p
|
||||
. ds L" ``
|
||||
. ds R" ''
|
||||
. ds C`
|
||||
. ds C'
|
||||
'br\}
|
||||
.\"
|
||||
.\" Escape single quotes in literal strings from groff's Unicode transform.
|
||||
@@ -48,17 +50,24 @@
|
||||
.\" 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"
|
||||
.\"
|
||||
.\" Avoid warning from groff about undefined register 'F'.
|
||||
.de IX
|
||||
..
|
||||
. nr % 0
|
||||
. rr F
|
||||
.\}
|
||||
.el \{\
|
||||
. de IX
|
||||
.nr rF 0
|
||||
.if \n(.g .if rF .nr rF 1
|
||||
.if (\n(rF:(\n(.g==0)) \{
|
||||
. if \nF \{
|
||||
. de IX
|
||||
. tm Index:\\$1\t\\n%\t"\\$2"
|
||||
..
|
||||
. if !\nF==2 \{
|
||||
. nr % 0
|
||||
. nr F 2
|
||||
. \}
|
||||
. \}
|
||||
.\}
|
||||
.rr rF
|
||||
.\"
|
||||
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
|
||||
.\" Fear. Run. Save yourself. No user-serviceable parts.
|
||||
@@ -124,7 +133,7 @@
|
||||
.\" ========================================================================
|
||||
.\"
|
||||
.IX Title "PCP1 1"
|
||||
.TH PCP1 1 "2015-08-17" "PCP 0.3.1" "USER CONTRIBUTED DOCUMENTATION"
|
||||
.TH PCP1 1 "2015-11-15" "PCP 0.3.1" "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
|
||||
@@ -233,9 +242,7 @@ Pretty Curved Privacy \- File encryption using eliptic curve cryptography.
|
||||
\& 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.
|
||||
\& an owner, mail and a passphrase.
|
||||
\& \-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
|
||||
@@ -342,7 +349,7 @@ Pretty Curved Privacy \- File encryption using eliptic curve cryptography.
|
||||
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.
|
||||
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
|
||||
@@ -668,10 +675,10 @@ Enable debugging output, where supported. Same as \fB\-D\fR.
|
||||
.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."
|
||||
.IX Item "0 No problems occurred."
|
||||
.PD 0
|
||||
.IP "1 Generic error code." 4
|
||||
.IX Item "1 Generic error code."
|
||||
.IX Item "1 Generic error code."
|
||||
.PD
|
||||
.SH "FILES"
|
||||
.IX Header "FILES"
|
||||
@@ -738,7 +745,7 @@ for the worst like passphrases like \*(L"aaa\*(R" or \*(L"x\*(R".
|
||||
.PP
|
||||
Pcp considers passphrases with an entropy measurement of 3.32 or higher
|
||||
as acceptable. This may change in the future.
|
||||
.SS "\s-1VAULT\s0 \s-1FORMAT\s0"
|
||||
.SS "\s-1VAULT FORMAT\s0"
|
||||
.IX Subsection "VAULT FORMAT"
|
||||
The vault file contains all public and secret keys. It's a portable
|
||||
binary file.
|
||||
@@ -785,7 +792,7 @@ Type can be one of:
|
||||
.Ve
|
||||
.PP
|
||||
The key header is followed by the actual key, see below.
|
||||
.SS "\s-1SECRET\s0 \s-1KEY\s0 \s-1FORMAT\s0"
|
||||
.SS "\s-1SECRET KEY FORMAT\s0"
|
||||
.IX Subsection "SECRET KEY FORMAT"
|
||||
A secret key is a binary structure with the following format:
|
||||
.PP
|
||||
@@ -854,7 +861,7 @@ 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-1PUBLIC\s0 \s-1KEY\s0 \s-1EXPORT\s0 \s-1FORMAT\s0"
|
||||
.SS "\s-1PUBLIC KEY EXPORT FORMAT\s0"
|
||||
.IX Subsection "PUBLIC KEY EXPORT FORMAT"
|
||||
Exported public and secret keys will be written in a portable
|
||||
way. Pcp uses \s-1RFC4880\s0 export format for public keys with some
|
||||
@@ -958,7 +965,7 @@ So, a full pubkey export looks like this
|
||||
\& hash
|
||||
\& signature
|
||||
.Ve
|
||||
.SS "\s-1SECRET\s0 \s-1KEY\s0 \s-1EXPORT\s0 \s-1FORMAT\s0"
|
||||
.SS "\s-1SECRET KEY EXPORT FORMAT\s0"
|
||||
.IX Subsection "SECRET KEY EXPORT FORMAT"
|
||||
Secret keys are exported in a proprietary format.
|
||||
.PP
|
||||
@@ -990,7 +997,7 @@ to encrypt the data and looks after encryption as such:
|
||||
.Vb 1
|
||||
\& Nonce | Cipher
|
||||
.Ve
|
||||
.SS "\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0"
|
||||
.SS "\s-1ENCRYPTED OUTPUT FORMAT\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
|
||||
@@ -1083,7 +1090,7 @@ of the sender.
|
||||
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"
|
||||
.SS "\s-1SIGNATURE FORMAT\s0"
|
||||
.IX Subsection "SIGNATURE FORMAT"
|
||||
There are different signature formats. Standard binary \s-1NACL\s0
|
||||
signatures have the following format:
|
||||
@@ -1135,15 +1142,15 @@ Armored signatures have the following format:
|
||||
.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"
|
||||
.SS "\s-1SIGNED ENCRYPTION FORMAT\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
|
||||
the standard encrypted file as described in \fB\s-1ENCRYPTED OUTPUT FORMAT\s0\fR
|
||||
followed by the binary encrypted signature described in \fB\s-1SIGNATURE FORMAT\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
|
||||
recipient list described in \fB\s-1ENCRYPTED OUTPUT FORMAT\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
|
||||
@@ -1183,7 +1190,7 @@ Before encryption the signature format is:
|
||||
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
||||
.Ve
|
||||
.PP
|
||||
where R is: C(recipient)|C(recipient)... (see \fB\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0\fR).
|
||||
where R is: C(recipient)|C(recipient)... (see \fB\s-1ENCRYPTED OUTPUT FORMAT\s0\fR).
|
||||
.PP
|
||||
Pseudocode:
|
||||
.PP
|
||||
@@ -1250,9 +1257,9 @@ pcp1 \-z \-I file \-O file.z85
|
||||
Reverse the process:
|
||||
.PP
|
||||
pcp1 \-Z \-I file.z85 \-O file
|
||||
.SS "\s-1PBP\s0 \s-1COMPATIBILITY\s0"
|
||||
.SS "\s-1PBP COMPATIBILITY\s0"
|
||||
.IX Subsection "PBP COMPATIBILITY"
|
||||
\&\s-1PCP\s0 tries to be fully compatible with \s-1PBP\s0 (https://github.com/stef/pbp). Encrypted
|
||||
\&\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
|
||||
@@ -1276,8 +1283,8 @@ functions:
|
||||
.PD
|
||||
.PP
|
||||
\&\s-1JSON\s0 support can be used either with the commandline tool \fBpcp1\fR or programmatically
|
||||
using the C, \*(C+ or Python \s-1API\s0.
|
||||
.SS "\s-1USING\s0 \s-1JSON\s0 \s-1FROM\s0 \s-1THE\s0 C \s-1API\s0"
|
||||
using the C, \*(C+ or Python \s-1API.\s0
|
||||
.SS "\s-1USING JSON FROM THE C API\s0"
|
||||
.IX Subsection "USING JSON FROM THE C API"
|
||||
In order to use \s-1JSON\s0 all you've got to do is to switch a context flag:
|
||||
.PP
|
||||
@@ -1287,9 +1294,9 @@ In order to use \s-1JSON\s0 all you've got to do is to switch a context flag:
|
||||
.Ve
|
||||
.PP
|
||||
That all to it. Now any function normally used for key import and export works
|
||||
with \s-1JSON\s0, just fill the \fBBuffer\fR object with a \s-1JSON\s0 string for imports or
|
||||
with \s-1JSON,\s0 just fill the \fBBuffer\fR object with a \s-1JSON\s0 string for imports or
|
||||
fetch the Buffer content of an export function as a string.
|
||||
.SS "\s-1USING\s0 \s-1JSON\s0 \s-1FROM\s0 \s-1THE\s0 \s-1COMMANDLINE\s0"
|
||||
.SS "\s-1USING JSON FROM THE COMMANDLINE\s0"
|
||||
.IX Subsection "USING JSON FROM THE COMMANDLINE"
|
||||
In order to use \s-1JSON\s0 on the commandline, add \fB\-j\fR. This can be used in
|
||||
conjunction with the following options:
|
||||
@@ -1307,9 +1314,9 @@ Public and secret key import.
|
||||
Text view mode (aka inspect mode).
|
||||
.PP
|
||||
The \fB\-z\fR and \fB\-Z\fR options are ignored in \s-1JSON\s0 mode.
|
||||
.SS "\s-1JSON\s0 \s-1OBJECT\s0 \s-1STRUCTURE\s0"
|
||||
.SS "\s-1JSON OBJECT STRUCTURE\s0"
|
||||
.IX Subsection "JSON OBJECT STRUCTURE"
|
||||
\fI\s-1JSON\s0 \s-1PUBLIC\s0 \s-1KEY\s0 (pcp1 \-p \-j)\fR
|
||||
\fI\s-1JSON PUBLIC KEY \s0(pcp1 \-p \-j)\fR
|
||||
.IX Subsection "JSON PUBLIC KEY (pcp1 -p -j)"
|
||||
.PP
|
||||
The \s-1JSON\s0 object for a public key looks like this:
|
||||
@@ -1338,7 +1345,7 @@ Fields containing byte arrays are hex encoded.
|
||||
.PP
|
||||
Numbers are represented as literal integers.
|
||||
.PP
|
||||
\fI\s-1JSON\s0 \s-1SECRET\s0 \s-1KEY\s0 (pcp1 \-s \-j)\fR
|
||||
\fI\s-1JSON SECRET KEY \s0(pcp1 \-s \-j)\fR
|
||||
.IX Subsection "JSON SECRET KEY (pcp1 -s -j)"
|
||||
.PP
|
||||
The \s-1JSON\s0 object for a public key looks like this:
|
||||
@@ -1369,7 +1376,7 @@ secret key material. Pcp does not support exporting a secret key unencrypted.
|
||||
The \fBnonce\fR is required for a later import and shall not be changed or
|
||||
decoupled from \fBsecrets\fR. This may change in the future.
|
||||
.PP
|
||||
\fI\s-1JSON\s0 \s-1VAULT\s0 (pcp1 \-t)\fR
|
||||
\fI\s-1JSON VAULT \s0(pcp1 \-t)\fR
|
||||
.IX Subsection "JSON VAULT (pcp1 -t)"
|
||||
.PP
|
||||
The \s-1JSON\s0 object for the vault looks like this:
|
||||
@@ -1388,7 +1395,7 @@ The \s-1JSON\s0 object for the vault looks like this:
|
||||
The field \fBkeys\fR is an array containing one or more of the already
|
||||
described key objects.
|
||||
.PP
|
||||
\fI\s-1JSON\s0 \s-1PROGRAM\s0 \s-1OUTPUT\s0\fR
|
||||
\fI\s-1JSON PROGRAM OUTPUT\s0\fR
|
||||
.IX Subsection "JSON PROGRAM OUTPUT"
|
||||
.PP
|
||||
Currently pcp does not support \s-1JSON\s0 program output, that is, success or
|
||||
@@ -1437,7 +1444,7 @@ under the \fB\s-1GPL\s0\fR as well.
|
||||
\&\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.
|
||||
Licensed under the \s-1GNU GENERAL PUBLIC LICENSE\s0 version 3.
|
||||
.SH "HOME"
|
||||
.IX Header "HOME"
|
||||
The homepage of Pretty Curved Privacy can be found on
|
||||
|
||||
Reference in New Issue
Block a user