On Thursday 04 June 2009 17:09:51 sich wrote: > Matthew Toseland a écrit : > > SSKs are 1KB and have rather high overheads. You need to insert a bunch of > > CHKs under the SSK, and to make that safe you need the CHK data to be > > encrypted. But also you need it for security, because *the SSK is > > predictable*! > > Hello, > > Can we have different CHK keys for the same file ? To avoid inserting > data if we know the keys before. It's for this that we have choose SSK > to generate a new keypair for each file.
Not sure I follow. You can encrypt it differently and thus get a different CHK. > > Why SSK are predictable if you generate a new keypair for each chunk ? > And generating a new keypare if you reinsert some chunk who was already > inserted ? Ok, if you generate a new keypair it's not predictable. I'm assuming there is some level of redundancy - if the downloader can't get the chunk, he'll ask for it again? > > > SSKs are not practical IMHO, because they are tiny, and furthermore they > > are predictable and thus can be used by an attacker just like a full > > reinsert with the original key could be. > > CHK is more interesting if we can have keys that are not based on the > content like the actual CHK. Yes, you just have to encrypt the chunk before inserting it. > > > The CHKs under the SSK would be unique yes. And you'd have to store the > > chunk key somewhere. > > If I understand, you say that we need to encrypt the chunk with random > key (how ?), then insert the encrypted chunk as CHK and then publish the > key to decrypt the encrypted chunk ? > We need some native support to encrypt and decrypt file easly... Any idea ? Hmmm, I guess. We do have the classes for encryption in the source code - PCFBMode and Rijndael. Isn't this going to be a plugin? > > Thanks :) > > sich On Thursday 04 June 2009 17:17:37 sich wrote: > Matthew Toseland a écrit : > > You should seriously consider working with infinity0, his searching plugin > > will provide distributed indexing. > > good neews :) :) > > > Why are you splitting the files up? Are you assuming that the key changes > > every time for security? If you are using CHKs you can simply reinsert the > > original file - we can provide an FCP option to only reinsert some blocks, > > this is not a big problem. The advantage is that if the data has been > > inserted, you can just download it, using the normal CHK key, and if it > > hasn't, and people start reinserting it, you will be able to pick up those > > blocks. The disadvantage is security: anyone who inserts predictable keys > > is vulnerable to attack. However, to avoid such vulnerability, you need to > > *encrypt the inserted data differently each time*! I am assuming you are > > using chunks consisting of many CHKs, maybe 1MB, with an SSK pointing to > > them? In which case the chunk will need to be encrypted before being > > inserted. > > I have answer on my other email. To have different keys. But using > random encryption with CHK is best yes. > > > They only publish the SSK after they have finished inserting the chunk? Ok. > > yep, we waiting that the insert is finish before we publish the key. Well, the attacker gets a data point for each time you announce the key. If you announce one chunk at a time, then he gets data points depending on how big the chunks are. > > > These are advantages of selective reinsertion, which can be implemented > > over FCP with normal keys. > > The best thing is to do this through the node with FCP... But at this > time I don't think that is possible no ? It might be possible to do FCP support for differently encrypted CHKs, if there is demand for it. > > sich
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
