[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

consistent pcp/pbp formats



Thomas von Dein wrote:
> a short update about the progress. I've made the following changes to
> pcp[1] so far:
> 
> - asymmetrically and symmetrically encrypted files are now created in
>   the same format as pbp does (binary output only). Verified to work
>   with symmetric mode only because of some open issues.
> 
> - the same applies for signatures, binary only as well. pcp has another
>   format for armored sigs (which I like better).
> 
> - crypt+sign is supported now as well (pcp only).

Hmm... so, it sign plaintext, but transmit signature unencrypted.

If attacker knows/expect content of message, he can discover (and prove) message
authorship.
This is not most likely scenario, but still totally not good. Signature should
be encrypted too.

And, same with pgp & co, it is vulnerable to "Surreptitious Forwarding" [1]:
Alice sends to Bob "I love you", Bob decrypt message, re-encrypt it to Charlie,
keeping Alice signature intact. To avoid this problem, you can include
"len(recipients list)|recipients list" in signed material (thus, any attempt to
alter recipient list will automagically invalidate signature) [XXX: not exactly
usual, requires review].

[1] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html#tth_sEc1.1

When you invent new protocol, it is very good idea too look at *existing
standards first*. And then learn from known mistakes in them :-)

> - pcp can import and export pbp public keys.
> 
> - encryption keys are derived using scrypt().
> 
> - crypto and signing keypairs are generated separately.
> 
> 
> The todo list contains a bunch of open issues anyway:
> 
> - we still need a consistent pubkey file format.
> 
> - we also need an agreement on armoring (base85 va z85).
> 
> - cipher mode: currently pbp (and pcp now) encrypts data in ECB mode
>   with a blocksize of 32k. I think CBC would be better, and I already

????????????????????????????? What ????????????????????????????????

With ECB, if you encrypt same block with same key, you have same ciphertext.
Attacker can identify repetitive content, identify blocks that are same with
blocks of known plaintext, etc. All that, obviously, bad.

With pbp encryption scheme, each 32kb block is encrypted with stream cipher with
*explicit random nonce*. Unlike ECB, if you encrypt same blocks on same key,
you'll have *different* ciphertext (as they used different nonces). None of
above ECB problems apply.

>   implemented it (enabled with ./configure --enable-cbc). We'd need an
>   agreement here as well.

> [1] https://github.com/TLINDEN/pcp