Re: Re: infinint, libdar

On Sun, 2004-05-09 at 06:34, Denis Corbin wrote:
> 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.


I mean a whole new field that would be of a similiar type to the
compression scheme flags. For example, 'g' for gpg, 's' for scramble,
'a' for aes, etc.



> 
> > 
> > 
> > 
> >
> > [...]
> > 
> > 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
> _______________________________________________
> Dar-discussions mailing list
> Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/dar-discussions



-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click