Noted on the tone. I’m just trying to say the most with the least words. Let me step back and say that I really like the idea of MaidSAFE and what you guys are doing
Please take a second and look at it from my point of view: it’s kind of hard to comment on the scheme or nail down a problem when it’s a moving target. First you said that only neighboring keys were xored, then you said that the current one was too, now it’s some combination of them. First you said the XOR is fluff or it’s preventing against a future attack on AES and now it’s actually to prevent a sort of known plaintext attack.
As far as the level of detail, I’m just looking for an algorithm in terms of crypto primitives (AES, SHA, etc.), not code. The system doc seems to have a reasonable one, but it is vague in places.
Regarding precision, let me lay out my critique:
- Without the XOR, the current scheme is not secure as knowing information about neighboring chunks allows decryption of the current chunk. We’ve agreed on this, if I am correct.
- So, the security of the system depends on the XOR.
- Without knowing what “key gen” does (I don’t see it in the doc), it’s hard to say at this point if the XOR is secure – in fact it might leak information.
- Neither the AES or XOR portion is sufficient by itself – so there are multiple points of failure. It’s not the best practice to have multiple points of failure. (The XOR scheme might even be insecure as it stands, but without more detail on it I can’t say)
I agree with you, no scheme is 100% correct. However, as you say, the approach needs to be correct. Is this approach correct? It’s not clear, but simpler, correct approaches exist.