Re: Re: encryption subsystem

On Wed, 2006-03-29 at 23:18 +0200, Denis Corbin wrote:
> Hello Wesley,
> 

I've done some work on actual coding:
http://cyr.kaylix.net/public/viewcvs/dar/branches/crypto-redesign/

Also, I have updated the design document to reflect changes you've
suggested.
http://cyr.kaylix.net/public/dar_crypto_subsystem_redesign.html


> Here follow my questions and remarks about your Crypto Subsystem 
> redesign you have drawn:
> 
> - what would be the role of the external caller? Who is it? ? I assume 
> in the following that it is just a program using libdar.

Yes, just the program using libdar.


> - I think you make confusion between an Interface and an API 
> (Application Interface). For example generic_file is an Interface it is 
> not intended to be used by an external application it is thus not an API.

Yes, I'll change the wording.

> - I do not agree, it is possible to extend the encryption settings 
> without breaking API compatibility. Just add a new item in the 
> appropriate enumeration and implement the new cypher as you wish. :-)

I don't mean just adding a new cipher, I mean adding new authentication
methods, verification and signing, etc. But I see the sentence you're
talking about. The major point was to avoid breaking the file format,
not the API, so I'll change the wording there too.

> - It would help the understanding if you define in your diagrams why 
> some objects are round and some others are squared while some arrows are 
> blue and some others are red.

Yes, I'll make a legend. Basically, rectangles are objects, circles are
interfaces.

> - What is the Session key? What's its role? I assume in the following 
> that its it a hash to be used in place of the passphrase?
> - Storing the "session key" in the archive seems to me a very bad idea, 
> it is not necessary and moreover will never be used.

The session key will be encrypted and will be used to decrypt the bulk
data. The advantage to using a session key two-fold:

1. It allows more than one authentication method per archive.
2. It makes public key authentication possible.

Public key authentication is impossible without this method because
asymmetric encryption is too slow for bulk data. Hence the encryption
key for a symmetric algorithm is encrypted with the public key protocol,
allowing *asymmetric authentication* with *symmetric encryption*.


> - by authentication objects do you mean signing the archive? Things that 
> let one know an archive has not been modified? Then one will maybe like 
> to just authenticate an archive but leave it in clear (=unencrypted).
> - It seems to be a confusion between authentication and encryptions. I 
> don't see where is authentication calculated nor where it is stored in 
> the archive, and moreover how can it be calculated while the archive is 
> not yet completed... (?)

In the document I take authentication to mean the act of allowing a user
to access something. Thus signing is verification, not authentication.
Authentication is also different from encryption:

Authentication: passwords, public keys, etc.
Encryption: The cipher encrypts data
Verification: Data signing


> - While it is obvious that is is necessary to store additional 
> information in the archive (in regard to the encryption cypher used for 
> example), if this information is archive-wide and must not be encrypted 
> it has its place in the archive header (header_version), while if it 
> must be encrypted (archive-wide or not), it has not its place in the 
> header_version. It must be encrypted with the rest of the data of the 
> archive (else we are subject to clear text attack).

There is no risk of clear text attack because the session key is
randomly generated. Whereas the cipher type (and other normalized data)
is actually not encrypted (it's in plaintext before the encrypted
payload).


> - the use of TLV (Type Length Value) structure in the header_version is 
> OK. It is extendable and easy to use, good idea!
> 
> 
> I agree, it is possible to improve dar's security and future expansion 
> about, in particular, the crypto subsystem. In particular, yes, the fact 
> that the passphrase is provided as-is is not very fair from libdar. 
> (while the user can provide any sequence of byte, it should maybe  be 
> interesting to make it have more entropy in a predictable manner).
> 
> yes, it is possible also to have an hash in the archive header (thus in 
> clear), that give a chance to detect that a passphrase is not correct, 
> but to be usable it must be in clear, which makes the encryption less 
> secure (this gives an noticeable indication about the characteristics of 
> the passphrase to anyone trying to crack the archive).

I've had to give this some thought. Cryptographic hashes are relatively
secure. In addition, the verification would actually be the first two
bytes of the hash, which would make it even harder to break the archive
by brute force.


> 
> No, the libdar caller must not indicate the block size, a default value 
> exists. The motivation that can lead one to change the block size from 
> default value is to have a secondary level of protection (one must know 
> the block size to be able to read the archive).

> So to summarize, tell me if I am wrong, you want:
> - to add new cypher algorithms, in particular those using asymmetric keys
> - have the possibility to detect a wrong key, by having a hash done on 
> the passphrase and stored in the archive

Yeap.


> - provide a mean to authenticate an archive

By authenticate I assume you mean verification through key signing. Yes,
but that is not covered in my design currently.

> - have passphrase been transformed to get in place a sequence with more 
> entropy to be used for encryption.

No, that's not the purpose of transforming the passphrase. The
passphrase would be transformed into a key to decrypt the session key,
which is used to decrypt bulk data.

> - replace the crypto parameters actually used in libdar API by a 
> reference to a crypto_container (or NULL for no 
> encryption/authentication) and extend the libdar API to let the user 
> manipulate (create/destroy/...) crypto_container easily. [Note for 
> further reference: this may cause problem in multi-threaded environment 
> except if such  object (which are passed as argument to libdar API 
> functions) are not stored inside libdar, but in the caller memory space]

This should not cause a problem with multi-threaded environments because
all of the objects are immutable from the client-side perspective after
the archive() call is made.


> 
> There is thus to be defined:
> - the class hierarchy for the crypto_container (with a pure virtual 
> class at the root for example)

There will only be one container class.

> - the API extensions that would let the user manipulate a 
> crypto_container (I think about something close to what has been done 
> for masks, thus let the user directly access the set of classes 
> previously defined and have it pass such objects as argument to 
> archive's methods).
> - the archive format modification if any. (in particular where and how 
> to store the hash on the passphrase, eventually whether the block size 
> will be stored in the archive, ... I think this is a bad idea as this 
> would be equivalent to hard code it in dar :-/ )

That is already defined in "Passphrase Authentication Payload" and
"Public Key Authentication Payload" in the design document. Those
structures represent the payload for the archive header extensions.

> - define the algorithm that will make passphrase get more entropy

The passphrase will not really get more entropy. The purpose of the
cryptographic hash to encrypt a session key is to allow more than one
type of authentication per archive. The S2K transformation is all that
would be performed (with a possibility of later adding different
hashes).

> 
> Last point, about the implementation you have briefly drawn, instead of 
> using macros, it would be more robust to use enumerations (see what is 
> done for compressor.hpp and crypto.hpp for example)

Yes, you're right. It will use enumerations.

> 
> 
> Kind Regards,
> Denis.
> 
> Denis Corbin wrote:
> > Wesley Leggette wrote:
> > 
> >> On Sat, 2006-03-25 at 10:27 +0100, Denis Corbin wrote:
> >>
> >>> Wesley Leggette wrote:
> >>>
> >>>> Denis,
> >>>
> >>>
> >>> Hello Wesley,
> >>>
> >>>
> >>
> >> [snip]
> >>
> >>
> >>>> Are you interested in discussing how the new design would work before I
> >>>> write it, or should I just go ahead and make an implementation?
> >>>
> >>>
> >>> Yes, I would be interested in a discussion about what your design 
> >>> before starting implementing it.
> >>
> >>
> >>
> >>
> >> I've pretty much laid out how I want to implement the new system. Look
> >> at this page:
> >>
> >> http://cyr.kaylix.net/public/dar_crypto_subsystem_redesign.html
> > 
> > 
> > OK, I will have a look at it as soon as possible, and will give you my 
> > feedback here.
> > 
> > Regards,
> > Denis.
-- 
Wesley Leggette <lists-+42/j/[email protected]>

GPG Key:         http://www.kaylix.net/kaylix.asc or http://pgp.mit.edu
GPG Fingerprint: 9B6F 19FB 5296 5E6C 21FE  7614 2A20 5688 F848 9BDD

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQBEKyOEKiBWiPhIm90RAgtMAJ9behjbW40CSgmELm7aQLnpaRKwCACcDbJw
p4QDOOD4HGscFeUUFGBZCg0=
=h6BH
-----END PGP SIGNATURE-----