@SqueamishOssifrage It sounds to me that transcribing it into pseudo-code could be a happy medium as it won't be executable but could be more readable to non-math folk.
@StevenHatzakis Why are you treating executability as if it's a bad thing? If the expository value is the same, why is it preferable to invent a new language that no machine on the planet will interpret in the hope that a human reader can guess what it means? Why is this a useful criterion to strive for? Why would you want to take a clear fragment of code that works and runs, and turn it into one that doesn't work?
And, let's take this criterion at face value. Suppose you wrote a fragment of ‘pseudocode’. Suppose, then, that someone did guess what you meant, and wrote an interpreter for the language that seems to execute the algorithm as you described it. Would that turn the ‘pseudocode’ from a good, admissible exposition into a bad, inadmissible exposition?
It actually goes much deeper than a mere question about exposition or rules on crypto.se; when we write papers with proofs of theorems that are only human-verifiable, and there are mistakes in the typography, those can be transcribed by humans into software that is then used for, oh, I dunno, managing billions of euros of economic value in the Zcash network, until someone notices the typo.
Or when the Swiss election authority writes a paper proving various security theorems, including anonymity and verifiability of the vote, and then some software drudge at a government contractor is tasked with transcribing the idea from the paper into code, and they pick a group element uniformly at random as required by Pedersen commitments by choosing an exponent uniformly at random and raising a standard base point to it…
Which makes it seem all the more positively bonkers to demand a gap between exposition and execution!
Note that nobody really posts "executable" code on Crypto.SE; you need more than just a code snippet for that (include statements etc.). Hence, at least with regards to the site, I'd rather talk about validated source code of a particular PL.
If you look in the OCB submission for CAESAR, you will see that the designers state the security is similar to that of GCM. I would note, however, that GCM has been shown to posses weak key classes, see for example:
https://eprint.iacr.org/2013/144.pdf
https://eprint.iacr.org/2011/202.pdf
http:...
I wasn't aware of weak keys. Is that actually true?
So TIL, that Robustness is the property of an AE cipher so that for any properly encrypted ciphertext you cannot find a second different key that also yields a successful decryption.
And even more amusingly GCM is not robust.
Which actually lead to an attack on the Facebook Messenger Content moderation system.
Also there is apparently a standardization effort going on I totally missed to standardize Messaging Layer Security (MLS) similar to TLS for a fancy group messaging protocol.
@FutureSecurity Ok, so I will now layout the attack here for you
So for large file attachments Facebook Messenger creates a commitment to the file's key
Then the file is encrypted with the key using AES-GCM
and send to the recipient. So far so good.
Now if you can find a second key that yields a valid encryption under that ciphertext, you again commit to the key and send the encrypted file.
Now, the recipient can also report your message at which point the cleartext with the commitment to the key will be sent to facebook.
However if one of these ciphertext decryptions is a harmless image and the other one is an abusive one and you do the ordering right, the system will deduplicate based on the ciphertexts (if I understood it correctly) and show the moderator the harmless image
(details and correct descriptions should be in the paper, section 3)
It's a shame EAX mode was never standardized officially. CCM is a PITA. If I'd trust anything it is probably EAX which basically is just CTR + CMAC in a predefined configuration.
Yeah, it is deterministic over the IV, AAD and plaintext or ciphertext commonly. I'll have to check if it was plaintext or ciphertext, I haven't got a photographic memory.
Um. Wait. That's always the case. What was the question again?
Ah, I don't see how you can get any information about CMAC by nonce-reuse, so generating a valid MAC for another message seems unlikely. I think that's what you were after, right?
Yeah, that's why I put in non-catastrophic :) And I presume such a stream cipher must be plaintext aware. There is of course CBC-CTS, but that also has some drawbacks.
Well, sometimes you just want to write the stuff directly to file and destroy (or not use / move) the file if there is a tag mismatch.
It's a bit of a shame if you cannot even create a good method of getting the plaintext without buffering it all in one contiguous, hidden block of memory.
LOL: you buy this media outlet and your companies get all government contracts. On video. "I was framed". That's correct, you were framed to be corrupt by a hidden camera.
@SqueamishOssifrage I never implied any of that, you misunderstood my comment. I saw that someone said that something like 'executable code is not permitted on crypto.stackexchange', which is a statement I haven't even verified, but I simply offered a solution where if someone had executable-code they wanted to share but were worried that it isn't permitted they can translate it to pseudo-code. I am not arguing which is better worse etc..
It would seem silly if it wasn't permitted except for on the main stackexchange site, again not sure if there is any truth to those requirements.
@FutureSecurity The putative theory of GHASH weak key classes is true and misleading and irrelevant, and the line of papers on the subject have led many people into regrettable confusion about the security of authenticators. I go into further detail here:
Saarinen in his work GCM, GHASH and Weak Keys says that;
This paper is not very clear and has led many people into regrettable confusion about universal hashing authenticators.
The paper contains misleading claims and misattribution of ideas; describes attacks that apply only beyond the bou...
@StevenHatzakis Right—what I'm responding to here is Maeher's suggestion that it is forbidden to illustrate questions with executable code:
@SqueamishOssifrage As I understand the scope of the site, yes.
@StevenHatzakis I agree that such a rule seems silly! I'm also not sure we have ever had such a rule on this site, and I don't think we ever should have such a rule on this site. As a guideline, it would be reasonable to say that you don't need to worry about making sure that an illustrative fragment of code is executable—that pseudocode can be a good way to illustrate a computational idea too. But that's a far cry from the frankly baffling rule that Maeher suggested we have.
@MaartenBodewes Most of the brittleness of AES-GCM comes from AES, not from GHASH. The only security problem with GHASH is that fast software implementations are essentially incompatible with side channel security. The data volume bounds on AES-GCM, for example, arise from the use of a permutation instead of a function. Poly1305 has essentially the same security as GHASH; crypto_secretbox_xsalsa20poly1305 is generally a superior alternative to AES-GCM because it uses XSalsa20 instead of AES-CTR.
@FutureSecurity The forger's success probability for a t-bit tag can't be bounded by anything lower than 1/2^t. For an n-block message in a polynomial evaluation MAC like Poly1305 or GHASH, it's n/2^t. At face value, this appears to mean that there's a big security penalty to truncating tags on long messages, and that's the usual story people tell (and that even I've echoed). But that story is a little unsatisfying.
@FutureSecurity Specifically, that story is unsatisfying because the ratio of the bandwidth spent attempting forgeries to the net success probability is not actually much higher for universal hashing MACs: maybe the forgery probability is bounded by 1000/2^t for a single 1000-block message, but it's also about 1000/2^t for a thousand 1-block messages, which costs only a factor of <2 more bandwidth (since there will be only one t-bit tag on the 1000-block message, vs. a thousand t-bit tags).
I presume that using CCM or EAX in this case doesn't make a difference w.r.t. security of the MAC (CBC-MAC with defined length messages vs CMAC) when it comes to forgery.
@MaartenBodewes Anything involving CBC with a b-bit block cipher will have a security cost of q^2/2^b where q is the number of blocks, so it's no good for more than 2^{b/2} blocks.
Basically, ≪256-bit block ciphers were a historical design mistake, and it seems the world has finally, many decades later, moved on to fixed permutations and systems built out of native PRFs instead of PRPs—except we standardized AES and SHA-2 and they've made it into widely deployed silicon so it's hard to get rid of them.
(Salsa20, ChaCha, SHA-3, Gimi, etc., are all built out of fixed permutations, and use them as building blocks for PRFs and other objects; very few protocols actually natively use PRPs.)
Roughly, here's the forgery probabilities side by side for q messages, t-bit tag, n-block messages, and a b-bit block cipher, which costs nq + t bits of bandwidth:
(The forgery probability with AES-GCM also includes an nq(nq - 1)/2^b term because of AES, of course. I'm not separately counting forgery attempts from legitimate messages; it doesn't substantially change the point, since forgeries may as well overwhelm legitimate messages to saturate the bandwidth.)
@MaartenBodewes More like: using AES, or a 128-bit block cipher, is the worst. Polynomial evaluation MACs provide ample security and much better performance than CBC-MAC; using a 128-bit block cipher is a mistake.
The paper is just irrelevant daydreaming about how screwed the cryptography is if the adversary improbably succeeds at forgery. But in that case, the adversary has already fooled your application into acting on a forged order, so there's no limit to how screwed your application might be!
Yes. AES should have been standardized with a 256-bit block size. And we should have chucked block ciphers out the window decades ago, long before they wound up ubiquitously in silicon.
Well, on the bright side we haven't seen any too many practical attacks yet, and it is infinitely better than 3DES. Crypto is a new field so we can enjoy thinking of new & better things.
(To be fair, GHASH is also bad because of the incompatibility between fast software implementation and side channel resistance! But its cryptanalytic security is plenty.)
yeah, when I was in the JavaCard forum I pressed for EAX to be included as those platforms don't have 32 bit processors let alone 128 bit vector calculations. CCM was still in there, but it's got usability issues.
Ugh, why does C# always have to re-invent everything that Java does? Span is nice in the sense that it doesn't carry state, but please give me the option to at least write things to a specific index instead of having to Slice endlessly.
If you look in the OCB submission for CAESAR, you will see that the designers state the security is similar to that of GCM. I would note, however, that GCM has been shown to posses weak key classes, see for example:
https://eprint.iacr.org/2013/144.pdf
https://eprint.iacr.org/2011/202.pdf
http:...
Saarinen in his work GCM, GHASH and Weak Keys says that;
This paper is not very clear and has led many people into regrettable confusion about universal hashing authenticators.
The paper contains misleading claims and misattribution of ideas; describes attacks that apply only beyond the bou...
The Side Channel
The Side Channel