3 ms·

Hello, very ignorant of crypto user question if you don't mind: In this system, do distributed encryptions of the same data cause any vector for attack? Eg, if

Hello, very ignorant of crypto user question if you don't mind: In this system, do distributed encryptions of the same data cause any vector for attack? Eg, if this library helps prevent nonce misuse, does distributing the writes of data across multiple computers cause possible problems? This may seem completely off the mark, so feel free to respond with a simple "No.", i'm very ignorant of this stuff. All i know, is to be very wary heh. My use case, for those curious, is that i've got a distributed , content addressed filesystem built ontop of a sort of ledger. This filesystem allows for offline writing, which of course means that when nodes reconnect, reconciliation of any data conflicts must take place. This is done on the ledger in a very bitcoiny way. Simply, stupid. In a nonce system (as described in the blog at least), i could simply use the length of the chain as the nonce and i'd be 100% safe from nonce reuse on the ledger. However, some writes of distributed nodes might duplicate nonces before reconciliation takes place. The ledger never has duplicates, but old-hash addresses would (temporarily) contain a duplicated nonce. Does this scenario sound bad for Miscreant? As an aside, thank you to all involved for this project! Friendly crypto will be such a boon to developers!

loup-vaillant 9y ago
An easy way to prevent nonce reuse is to use a nonce big enough to be selected at random. 192 bits is big enough. XChacha20 provides that. I believe there are more general nonce extension constructions out there, but I don't know enough to recommend any. If for some reason you cannot (or don't want to) rely on your system's random number generator, consider using a hash of the chain as the nonce. Just make sure duplicated chains never happen, or revealing the existence and location of duplicates is not a problem. If you need to mitigate replay attacks… Err… I don't know.
lvh 9y ago
Is there a good reason why you can't just randomize the nonce and use a large-nonce scheme? Are the collisions you're talking about just because they happen at the same ledger length, or is there reason to believe the writes are the same data?
geofft 9y ago
With some disclaimers that it's been a while since I've done this and also probably you should verify crypto advice you get from a web forum anyway: Reusing the same nonce and key to encrypt two different messages is very, very bad: in most schemes it leaks a lot of information about the plaintext and/or the key immediately. One easy conceptual example is CTR mode (or any of the authenticated-encryption modes based on CTR), which uses the key and nonce to generate a stream of bits that are then XOR'd with the plaintext. If you encrypt two plaintexts with the same stream, an attacker can XOR them together and the encryption cancels out, which basically reduces the attacker's problem to just the sort of cryptanalysis that was popular in the pre-computer era. (This is the exact same problem with using a one-time pad twice.) Reusing the same nonce and key to encrypt the same message is only bad in the sense that you'll get the same ciphertext. Most good cryptographic systems attempt to avoid leaking even the bit of information that two ciphertexts exhibit the same plaintext, and using unique nonces (or random nonces from a large-enough space of possible nonces) gets you that. SIV and therefore Miscreant leaks this information, but remains secure if you're encrypting two different messages. For some protocols, leaking information about a message being repeated is bad - imagine an online poker game, where the message is what card your opponent has. If you see the same ciphertext twice, probably that gives you a significant advantage. For some protocols, possibly including the distributed reconciliation you're talking about, maybe that's totally fine. Also, SIV (and therefore Miscreant) is quite a bit slower than other schemes, because it processes the message to compute the nonce and then again to encrypt the message now that it knows how to do that. For some protocols this is a big tradeoff. Since you mention "distributed filesystem" and "bitcoiny," I'll guess that's not a problem for you, but also given those constraints, probably just using a random IV selected from a large space is easy to do, so you might as well do that. Maybe do that and also use SIV, if you don't trust your users' offline RNGs. Since you mention content-addressed filesystems, take a look at the message-locked encryption construction, which is at a high level just SIV taken to an extreme: instead of just deriving the IV, you also derive the key from the hash of the message. This is a good primitive for building cross-user deduplication for something like an end-to-end encrypted version of Dropbox, because two unrelated users who happen to have the same file will produce the same ciphertext, while (at least in theory) if you were never in possession of the cleartext, you have no way to compute the key that was used to encrypt the ciphertext. However, it's got some inherent tradeoffs just by the nature of the problem, so if you don't need dedup across mutually untrusted users, don't use it. If you do, and you want your files to be content-addressed across users, MLE will make sure different users get the same ciphertexts and therefore the same hashes of ciphertexts for the same input files.

loup-vaillant 9y ago

An easy way to prevent nonce reuse is to use a nonce big enough to be selected at random. 192 bits is big enough. XChacha20 provides that. I believe there are more general nonce extension constructions out there, but I don't know enough to recommend any. If for some reason you cannot (or don't want to) rely on your system's random number generator, consider using a hash of the chain as the nonce. Just make sure duplicated chains never happen, or revealing the existence and location of duplicates is not a problem. If you need to mitigate replay attacks… Err… I don't know.

lvh 9y ago

Is there a good reason why you can't just randomize the nonce and use a large-nonce scheme? Are the collisions you're talking about just because they happen at the same ledger length, or is there reason to believe the writes are the same data?

geofft 9y ago

With some disclaimers that it's been a while since I've done this and also probably you should verify crypto advice you get from a web forum anyway: Reusing the same nonce and key to encrypt two different messages is very, very bad: in most schemes it leaks a lot of information about the plaintext and/or the key immediately. One easy conceptual example is CTR mode (or any of the authenticated-encryption modes based on CTR), which uses the key and nonce to generate a stream of bits that are then XOR'd with the plaintext. If you encrypt two plaintexts with the same stream, an attacker can XOR them together and the encryption cancels out, which basically reduces the attacker's problem to just the sort of cryptanalysis that was popular in the pre-computer era. (This is the exact same problem with using a one-time pad twice.) Reusing the same nonce and key to encrypt the same message is only bad in the sense that you'll get the same ciphertext. Most good cryptographic systems attempt to avoid leaking even the bit of information that two ciphertexts exhibit the same plaintext, and using unique nonces (or random nonces from a large-enough space of possible nonces) gets you that. SIV and therefore Miscreant leaks this information, but remains secure if you're encrypting two different messages. For some protocols, leaking information about a message being repeated is bad - imagine an online poker game, where the message is what card your opponent has. If you see the same ciphertext twice, probably that gives you a significant advantage. For some protocols, possibly including the distributed reconciliation you're talking about, maybe that's totally fine. Also, SIV (and therefore Miscreant) is quite a bit slower than other schemes, because it processes the message to compute the nonce and then again to encrypt the message now that it knows how to do that. For some protocols this is a big tradeoff. Since you mention "distributed filesystem" and "bitcoiny," I'll guess that's not a problem for you, but also given those constraints, probably just using a random IV selected from a large space is easy to do, so you might as well do that. Maybe do that and also use SIV, if you don't trust your users' offline RNGs. Since you mention content-addressed filesystems, take a look at the message-locked encryption construction, which is at a high level just SIV taken to an extreme: instead of just deriving the IV, you also derive the key from the hash of the message. This is a good primitive for building cross-user deduplication for something like an end-to-end encrypted version of Dropbox, because two unrelated users who happen to have the same file will produce the same ciphertext, while (at least in theory) if you were never in possession of the cleartext, you have no way to compute the key that was used to encrypt the ciphertext. However, it's got some inherent tradeoffs just by the nature of the problem, so if you don't need dedup across mutually untrusted users, don't use it. If you do, and you want your files to be content-addressed across users, MLE will make sure different users get the same ciphertexts and therefore the same hashes of ciphertexts for the same input files.