mirror of
https://codeberg.org/scip/pcp.git
synced 2025-12-16 19:40:57 +01:00
added check for weak passphrase using entropy test
This commit is contained in:
git@daemon.de
@@ -286,6 +286,26 @@ B<In short: don NOT use this software for production purposes!>
|
||||
|
||||
=head1 INTERNALS
|
||||
|
||||
=head2 PASSPHRASES
|
||||
|
||||
Passphrases are used to protect secret data at rest on various instances
|
||||
by pcp, like secret keys or symmetric encrypted data.
|
||||
|
||||
Pcp doesn't use the passphrase directly but uses a key derivation function
|
||||
to calculate a secure key from the passphrase: libsodium's
|
||||
B<crypto_pwhash_scryptsalsa208sha256()> function.
|
||||
|
||||
In order to properly protect secret keys, pcp measures the entropy
|
||||
of a given passphrase and warns the user about the possible weak
|
||||
passphrase. This measurement is calculated using the Claude E. Shannon
|
||||
method, where a value of 8.0 means maximum available entropy (e.g.
|
||||
truly random 256 chars in no comprehensible order) and 0.0 stands
|
||||
for the worst like passphrases like "aaa" or "x".
|
||||
|
||||
Pcp considers passphrases with an entropy measurement of 3.32 or higher
|
||||
as acceptable. This may change in the future.
|
||||
|
||||
|
||||
=head2 VAULT FORMAT
|
||||
|
||||
The vault file contains all public and secret keys. It's a portable
|
||||
|
||||
101
man/pcp1.1
101
man/pcp1.1
@@ -1,4 +1,4 @@
|
||||
.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
|
||||
.\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.16)
|
||||
.\"
|
||||
.\" Standard preamble:
|
||||
.\" ========================================================================
|
||||
@@ -38,8 +38,6 @@
|
||||
. ds PI \(*p
|
||||
. ds L" ``
|
||||
. ds R" ''
|
||||
. ds C`
|
||||
. ds C'
|
||||
'br\}
|
||||
.\"
|
||||
.\" Escape single quotes in literal strings from groff's Unicode transform.
|
||||
@@ -50,24 +48,17 @@
|
||||
.\" 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.
|
||||
.\"
|
||||
.\" Avoid warning from groff about undefined register 'F'.
|
||||
.de IX
|
||||
.ie \nF \{\
|
||||
. de IX
|
||||
. tm Index:\\$1\t\\n%\t"\\$2"
|
||||
..
|
||||
. 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.
|
||||
@@ -133,7 +124,7 @@
|
||||
.\" ========================================================================
|
||||
.\"
|
||||
.IX Title "PCP1 1"
|
||||
.TH PCP1 1 "2015-08-15" "PCP 0.3.1" "USER CONTRIBUTED DOCUMENTATION"
|
||||
.TH PCP1 1 "2015-08-17" "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
|
||||
@@ -351,7 +342,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
|
||||
@@ -677,10 +668,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"
|
||||
@@ -729,7 +720,25 @@ don't use it for anything remotely serious.
|
||||
\&\fBIn short: don \s-1NOT\s0 use this software for production purposes!\fR
|
||||
.SH "INTERNALS"
|
||||
.IX Header "INTERNALS"
|
||||
.SS "\s-1VAULT FORMAT\s0"
|
||||
.SS "\s-1PASSPHRASES\s0"
|
||||
.IX Subsection "PASSPHRASES"
|
||||
Passphrases are used to protect secret data at rest on various instances
|
||||
by pcp, like secret keys or symmetric encrypted data.
|
||||
.PP
|
||||
Pcp doesn't use the passphrase directly but uses a key derivation function
|
||||
to calculate a secure key from the passphrase: libsodium's
|
||||
\&\fB\f(BIcrypto_pwhash_scryptsalsa208sha256()\fB\fR function.
|
||||
.PP
|
||||
In order to properly protect secret keys, pcp measures the entropy
|
||||
of a given passphrase and warns the user about the possible weak
|
||||
passphrase. This measurement is calculated using the Claude E. Shannon
|
||||
method, where a value of 8.0 means maximum available entropy (e.g.
|
||||
truly random 256 chars in no comprehensible order) and 0.0 stands
|
||||
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"
|
||||
.IX Subsection "VAULT FORMAT"
|
||||
The vault file contains all public and secret keys. It's a portable
|
||||
binary file.
|
||||
@@ -776,7 +785,7 @@ Type can be one of:
|
||||
.Ve
|
||||
.PP
|
||||
The key header is followed by the actual key, see below.
|
||||
.SS "\s-1SECRET KEY FORMAT\s0"
|
||||
.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
|
||||
@@ -845,7 +854,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 KEY EXPORT FORMAT\s0"
|
||||
.SS "\s-1PUBLIC\s0 \s-1KEY\s0 \s-1EXPORT\s0 \s-1FORMAT\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
|
||||
@@ -949,7 +958,7 @@ So, a full pubkey export looks like this
|
||||
\& hash
|
||||
\& signature
|
||||
.Ve
|
||||
.SS "\s-1SECRET KEY EXPORT FORMAT\s0"
|
||||
.SS "\s-1SECRET\s0 \s-1KEY\s0 \s-1EXPORT\s0 \s-1FORMAT\s0"
|
||||
.IX Subsection "SECRET KEY EXPORT FORMAT"
|
||||
Secret keys are exported in a proprietary format.
|
||||
.PP
|
||||
@@ -981,7 +990,7 @@ to encrypt the data and looks after encryption as such:
|
||||
.Vb 1
|
||||
\& Nonce | Cipher
|
||||
.Ve
|
||||
.SS "\s-1ENCRYPTED OUTPUT FORMAT\s0"
|
||||
.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
|
||||
@@ -1074,7 +1083,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 FORMAT\s0"
|
||||
.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:
|
||||
@@ -1126,15 +1135,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 ENCRYPTION FORMAT\s0"
|
||||
.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 OUTPUT FORMAT\s0\fR
|
||||
followed by the binary encrypted signature described in \fB\s-1SIGNATURE FORMAT\s0\fR
|
||||
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 OUTPUT FORMAT\s0\fR as well. A
|
||||
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
|
||||
@@ -1174,7 +1183,7 @@ Before encryption the signature format is:
|
||||
\& +\-\-\-\-\-\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-|\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-+
|
||||
.Ve
|
||||
.PP
|
||||
where R is: C(recipient)|C(recipient)... (see \fB\s-1ENCRYPTED OUTPUT FORMAT\s0\fR).
|
||||
where R is: C(recipient)|C(recipient)... (see \fB\s-1ENCRYPTED\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0\fR).
|
||||
.PP
|
||||
Pseudocode:
|
||||
.PP
|
||||
@@ -1241,9 +1250,9 @@ pcp1 \-z \-I file \-O file.z85
|
||||
Reverse the process:
|
||||
.PP
|
||||
pcp1 \-Z \-I file.z85 \-O file
|
||||
.SS "\s-1PBP COMPATIBILITY\s0"
|
||||
.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
|
||||
\&\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
|
||||
@@ -1267,8 +1276,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 JSON FROM THE C API\s0"
|
||||
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"
|
||||
.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
|
||||
@@ -1278,9 +1287,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 JSON FROM THE COMMANDLINE\s0"
|
||||
.SS "\s-1USING\s0 \s-1JSON\s0 \s-1FROM\s0 \s-1THE\s0 \s-1COMMANDLINE\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:
|
||||
@@ -1298,9 +1307,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 OBJECT STRUCTURE\s0"
|
||||
.SS "\s-1JSON\s0 \s-1OBJECT\s0 \s-1STRUCTURE\s0"
|
||||
.IX Subsection "JSON OBJECT STRUCTURE"
|
||||
\fI\s-1JSON PUBLIC KEY \s0(pcp1 \-p \-j)\fR
|
||||
\fI\s-1JSON\s0 \s-1PUBLIC\s0 \s-1KEY\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:
|
||||
@@ -1329,7 +1338,7 @@ Fields containing byte arrays are hex encoded.
|
||||
.PP
|
||||
Numbers are represented as literal integers.
|
||||
.PP
|
||||
\fI\s-1JSON SECRET KEY \s0(pcp1 \-s \-j)\fR
|
||||
\fI\s-1JSON\s0 \s-1SECRET\s0 \s-1KEY\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:
|
||||
@@ -1360,7 +1369,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 VAULT \s0(pcp1 \-t)\fR
|
||||
\fI\s-1JSON\s0 \s-1VAULT\s0 (pcp1 \-t)\fR
|
||||
.IX Subsection "JSON VAULT (pcp1 -t)"
|
||||
.PP
|
||||
The \s-1JSON\s0 object for the vault looks like this:
|
||||
@@ -1379,7 +1388,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 PROGRAM OUTPUT\s0\fR
|
||||
\fI\s-1JSON\s0 \s-1PROGRAM\s0 \s-1OUTPUT\s0\fR
|
||||
.IX Subsection "JSON PROGRAM OUTPUT"
|
||||
.PP
|
||||
Currently pcp does not support \s-1JSON\s0 program output, that is, success or
|
||||
@@ -1428,7 +1437,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 GENERAL PUBLIC LICENSE\s0 version 3.
|
||||
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
|
||||
|
||||
1525
man/pcp1.html
1525
man/pcp1.html
File diff suppressed because it is too large
Load Diff
20
man/pcp1.pod
20
man/pcp1.pod
@@ -601,6 +601,26 @@ B<In short: don NOT use this software for production purposes!>
|
||||
|
||||
=head1 INTERNALS
|
||||
|
||||
=head2 PASSPHRASES
|
||||
|
||||
Passphrases are used to protect secret data at rest on various instances
|
||||
by pcp, like secret keys or symmetric encrypted data.
|
||||
|
||||
Pcp doesn't use the passphrase directly but uses a key derivation function
|
||||
to calculate a secure key from the passphrase: libsodium's
|
||||
B<crypto_pwhash_scryptsalsa208sha256()> function.
|
||||
|
||||
In order to properly protect secret keys, pcp measures the entropy
|
||||
of a given passphrase and warns the user about the possible weak
|
||||
passphrase. This measurement is calculated using the Claude E. Shannon
|
||||
method, where a value of 8.0 means maximum available entropy (e.g.
|
||||
truly random 256 chars in no comprehensible order) and 0.0 stands
|
||||
for the worst like passphrases like "aaa" or "x".
|
||||
|
||||
Pcp considers passphrases with an entropy measurement of 3.32 or higher
|
||||
as acceptable. This may change in the future.
|
||||
|
||||
|
||||
=head2 VAULT FORMAT
|
||||
|
||||
The vault file contains all public and secret keys. It's a portable
|
||||
|
||||
@@ -87,8 +87,12 @@ void pcp_keygen(char *passwd) {
|
||||
|
||||
if(strnlen(passphrase, 1024) > 0) {
|
||||
double ent = pcp_getentropy(passphrase);
|
||||
if(ent < 3) {
|
||||
fprintf(stderr, "WARNING: you are using a weak passphrase (entropy: %lf)\n", ent);
|
||||
if(ent < 3.32) {
|
||||
fprintf(stderr, "WARNING: you are using a weak passphrase (entropy: %lf)!\n", ent);
|
||||
char *yes = pcp_getstdin("Are you sure to use it [yes|NO]?");
|
||||
if(strncmp(yes, "yes", 1024) != 0) {
|
||||
goto errkg1;
|
||||
}
|
||||
}
|
||||
key = pcpkey_encrypt(ptx, k, passphrase);
|
||||
}
|
||||
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
pcp = ../src/pcp1
|
||||
vault = v1
|
||||
passwd = xxx
|
||||
passwd = ech9xeiT%CuxuH1ch-is2ies1R
|
||||
md5msg = 66b8c4ca9e5d2a7e3c0559c3cdea3d50
|
||||
mangle = ./mangle
|
||||
verbose = 1
|
||||
@@ -106,6 +106,17 @@ dxmorg@florida.cops.gov
|
||||
expect = /Generated new secret key/
|
||||
</test>
|
||||
|
||||
<test check-fail-entropy-generate-secret-key>
|
||||
cmd = $pcp -V $vault -k -x password
|
||||
input = <<EOF
|
||||
Dexter Morgan
|
||||
dxmorg@florida.cops.gov
|
||||
no
|
||||
EOF
|
||||
expect = /weak passphrase/
|
||||
</test>
|
||||
|
||||
|
||||
|
||||
<test check-if-vault-contains-secret>
|
||||
cmd = $pcp -V $vault -l
|
||||
@@ -533,7 +544,7 @@ temporarily disabled
|
||||
#
|
||||
# input handling tests
|
||||
<test check-large-meta>
|
||||
cmd = (./jot 300 | while read m; do echo -n m; done; echo xxx) \
|
||||
cmd = (./jot 300 | while read m; do echo -n m; done; echo $passwd) \
|
||||
| $pcp -V $vault -k -x $passwd
|
||||
expect = /Generated new secret key/
|
||||
</test>
|
||||
@@ -541,9 +552,9 @@ temporarily disabled
|
||||
#
|
||||
# fuzz tests
|
||||
<test check-fuzz>
|
||||
prepare = (echo F; echo F) | $pcp -V vfz -k -x a; \
|
||||
$pcp -V vfz -p -O testfuzzP.orig -x a; \
|
||||
$pcp -V vfz -s -O testfuzzS.orig -x a;
|
||||
prepare = (echo F; echo F) | $pcp -V vfz -k -x $passwd; \
|
||||
$pcp -V vfz -p -O testfuzzP.orig -x $passwd; \
|
||||
$pcp -V vfz -s -O testfuzzS.orig -x $passwd;
|
||||
<test check-fuzz-binary-pubkey>
|
||||
loop = 30
|
||||
prepare = while :; do \
|
||||
@@ -553,7 +564,7 @@ temporarily disabled
|
||||
break; \
|
||||
fi; \
|
||||
done
|
||||
cmd = echo no | $pcp -V vf -K -I testfuzzP.pub -x a
|
||||
cmd = echo no | $pcp -V vf -K -I testfuzzP.pub -x $passwd
|
||||
expect = !/added/
|
||||
</test>
|
||||
<test check-fuzz-binary-seckey>
|
||||
@@ -565,7 +576,7 @@ temporarily disabled
|
||||
break; \
|
||||
fi; \
|
||||
done
|
||||
cmd = echo no | $pcp -V vf -K -I testfuzzS.sec -x a
|
||||
cmd = echo no | $pcp -V vf -K -I testfuzzS.sec -x $passwd
|
||||
expect = !/added/
|
||||
</test>
|
||||
</test>
|
||||
|
||||
Reference in New Issue
Block a user