Hi,
> Pierre Jaury writes:
> > This software is still an early research project: as far as I know, only
> > basic formal security analysis has been performed.
>
> Ok, just make sure that the users know about this.
They will. Additionally, I plan on preparing the project for definitive
packaging once some crucial bugs I already reported are fixed upstream.
By the way, a detailed cryptographic analysis is currently being
performed for vodstok protocol. The only spotted weakness is the single
AES key being used for many related chunks, even if those are uploaded
to various locations and named pseudo-randomly. Yet, an additional
feature is being designed that will allow multiple keys to be used
(ultimately, one key per chunk). vodstok could also use AES CBC (or any
chained mode) as well as ECB for small files, ie. when downloading the
whole file before decrypting remains an option.
> > Yet, for your specific concern about usual AES vulnerability when using
> > independently encrypted blocks, the project aims at providing temporary
> > private storage but does not pretend to provide secure operations.
>
> Ok, next question is then: how does vodstok detects tampering done by
> hostile peers?
There is no reason for vodstok to detect tampering, as long as design
choices ensure that the system is reliable enough for temporary storage
of non-critical files.
First, repositories have a maximum amount of disk space to allocate.
Once it is full, a repository will automatically delete old chunks to
free enough disk space for the new uploaded files to be stored.
Because uploaded chunks have a limited lifetime, there is a significant
risk that a file lacks some chunks before it is successfully downloaded
by clients. To avoid such a phenomenon, repositories publish statistics
about the average lifetime of chunks; client software use these
statistics to distribute the chunks so that small repositories are not
overloaded.
In case of an attacker flooding a repository with dummy chunks to
quickly delete the useful ones, two mechanisms will mitigate the
attempt. Timers are set so that a repository is not simply being flooded
by some dumb client. Plus, the deletion mechanism relies on a
most-recently-used list (and soon a most-frequently-used list) to ensure
that chunks belonging to popular files are not deleted.
> Two separate binary packages might make sense in that case yes but
> they'll of course be part of the same source package I assume?
Yes.
Regards,
Pierre.
signature.asc
Description: This is a digitally signed message part
