Re: infinint, libdar

Wesley Leggette wrote:
> On Mon, 2004-05-03 at 11:38, Denis Corbin wrote:
>[...]
> 
> 
> I'm a little confused as to what to dilema is with gpg'ing files
> individually as they're added to the archive. Can you clarify this for
> me?

Well, I am not an encryption expert at all, but I have been taught (and 
using some common sense I understand too), that if you reinitialize the 
encryption algorithm at each file boundary, you will have a less well 
protected data than when you encrypt the global archive. I cannot argue 
much about that, but I think it makes sens. What would be a good 
encryption algorithm poorly used in dar ? A waste of time for me, only :-/

Note that the current (weak) algorithm "scramble" is used on the whole 
archive, and does not know anything about file boundaries. The advantage 
of this simple algorithm is that you can decode any part just given its 
offset from the beginning of the encryption part, you don't need to 
decrypt some or all of the data found before in this same file.

> 
> Also, would it be too much to ask that a seperate encryption type flag
> be added to the next file format revision of dar? I would like to try
> adding various encryption schemes to my library, but I want to keep the
> library writing the standard dar format.

No there is no problem adding a new flag:

	const int VERSION_FLAG_CRYPTO_WESLEY = 0x10;

Hope you like its name ;-) else, it can be changed.

> 
> 
> 
>
> [...]
> 
> As far as dar and kdar, I use Gnome. So there you go. My program will be
> a GTK app. gdar really. In the end, I'll be using kdar as a basis for my
> implementation. I'll be focusing a lot on the features of dar_manager as
> well (great utility!).

Yes, unfortunately for now, dar_manager is not yet part of the API, but 
well, one day... OK, you are not affected because you don't rely on 
libdar ;-)

>[...]
> 
> 
> I'm not sure if I'm on the right track here, but if you've got a split
> archive that you're writing to pipe, how is the slice header changed to
> non terminal at the end of writing the archive? Or can you only write an
> archive to pipe if it's not sliced up?

You must see it in two layers. The first one is the general file 
disposition of an archive, if it is sliced or not and how [sar.hpp/cpp 
module], if it is local or remote archive [zapette.hpp/cpp module]. Over 
this first layer takes place a second one: the general archive structure 
which contains version_header + data + catalogue + terminateur.

The first layer hides the file disposition to the second, and gives it 
the impression that the archive is a single file whatever it is 
segmented or not, local or remote.

The sar module (segmentation and reassemblement, which term comes from 
the computer's network domain), receive any read, write or skip 
directives from the second layer, and tranlate them in open(), lseek(), 
read() and write() close() system calls, to corresponding real files. 
While the zapette module, receive theses same directives and translates 
it to requests sent to a first pipe and which at the other end generate 
replies sent back through another pipe. At each end of the pipe the 
processes share a common format to exchange data, (requests and reply). 
This exchange algorithm is very simple, as it relies on TCP so no 
acknoledgment is needed, nor retransmissions, nor reordering ...

The dar_slave program implements the server part of this exchange 
algorithm and dar the client part. dar_slave acts as gateway between sar 
and zapette and only acts at the first layer level, it does not know 
anything about the second layer structure (data, catalogue, terminateur, 
etc.). Same thing about dar_xform which acts only at the first layer, 
and is a gateway between two sar objects (with different parameters, 
making it possible to change the slice sizes, for example).

Only dar (libdar now) is aware of the second layer. Just a remark: as 
this layer is thought as stored in a virtual single (sometimes huge) 
file, the offset of the data corresponding to a given file found in the 
catalogue is an absolute offset in bytes from the start of this virtual 
file (there is not direct information about which slice it is placed 
int). So you can cut this virtual file in as many and as smaller pieces 
(20 bytes) as you want, while you properly present a virtual file, built 
with theses pieces, to the second layer all works fine.

In fact there is more than two layers, between the two described above, 
can take place a compression layer, and a crypto layer for example.

You can have a look at the doc/NOTES files paragraphs IV.


Cheers,
Denis.




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3