Hi, > Pierre Jaury <pierre@jaury.eu> 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.
Attachment:
signature.asc
Description: This is a digitally signed message part