Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@zHXyHkzWuwUI It's also not deterministic, though; see the second property listed on that page

@ben There's quite a bit of history of convergent encryption in P2P software, long predating Maidsafe. Some notable ones include Freenet, GNUNet, and Tahoe-LAFS.

But crucially, there are several known attacks: https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html - and so if an implementation claims that it is "as safe as any other modern encryption algorithm", that is a strong claim that requires supporting rationale (which I do not see here).

@dequbed What would a more standard approach be for this usecase?

@ben That library is not very confidence-inspiring, to be honest - I haven't forgotten about Maidsafe's original sketchy business model (that they now pretend they've never had), and it speaks of an "additional obfuscation step" but then doesn't seem to provide any details about how that works or why it would be more secure than other approaches (or its vulnerability or lack thereof to known attacks against convergent encryption).

@dequbed The honest answer is that I have no idea :)

My rationale was something along the lines of: stay as close as possible to the standard recommended approach, and verify that specific deviations do not break the security model (I do not like rolling my own crypto).

By that reasoning, the closest thing that does what I want is "it still has a nonce, but it can be derived from the content/key". It's very possible that that's functionally indistinguishable from a nonce of zero - I simply don't know whether that is true! And so I did not take that step in my approach (yet).

@bananas If I can find the relevant documentation, yes 😅

@bananas Isn't a content-derived key scheme inherently secure against those types of attacks (as long as the hash function is)? As there is no way to obtain different ciphertexts from the same key

@unnick Huh. Isn't ed25519 public-key crypto rather than secret-key?

@bananas Yep, I'm aware of confirmation attacks - in this case, that's an acceptable weakness in the scheme (as it seems to be unavoidable if you want convergent encryption)

@benaryorg (Which has been an absolute pain in the design process, but that's a different discussion 🙃)

@benaryorg That's not sufficiently deterministic for my case, unfortunately; part of the protocol involves "checking if encrypted/sharded chunks already exist in the storage cluster, before uploading anything", for which the whole process (encoding, encryption, sharding) needs to be fully deterministic with zero 'external' malleable factors

@benaryorg The problem is that just about everything seems to require a nonce nowadays. Which is understandable, given how important it is for typical cases, but convergent encryption is very much an edgecase.

@bananas Right, but I'm looking to understand the actual cryptographic implications, rather than just following a rule of thumb, which may or may not apply here.

My understanding, for example, is that the *reason* for nonces being single-use, is that if you reuse them across plaintexts/ciphertexts, you can end up divulging information about the key used. But in this case, there is still a guarantee that they are not reused between *different* plaintexts, only identical ones (since it is derived from the plaintext with a cryptographic hash).

So does that mean that the actual necessary property of a nonce is still upheld here? Or is there some *other* reason why nonces need to be unique, that this is not accounting for?