Re: encryption subsystem

Hello Wesley,

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.
- 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.
- 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. :-)
- 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.
- 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.
- 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... (?)
- 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).
- 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).

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
- provide a mean to authenticate an archive
- have passphrase been transformed to get in place a sequence with more 
entropy to be used for encryption.
- 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]

There is thus to be defined:
- the class hierarchy for the crypto_container (with a pure virtual 
class at the root for example)
- 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 :-/ )
- define the algorithm that will make passphrase get more entropy

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)


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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEKvmhpC5CI8gYGlIRAjA8AKC18LJ6MpuEozvlXyvgeC3unQ3cZgCbBU/t
U0b4v1z7cW176M+tHp13BJ0=
=erw2
-----END PGP SIGNATURE-----