sup /g/ents
I need a discussion on block cipher modes of operation. Also, general crypto thread.
Right now, we have the following block cipher modes of operation available:
ECB - unsafe if encrypting data size > cipher block size
CBC - any type of feedback mode of operation should be considered unsafe or weakened, see [1]
PCBC - see CBC
CFB - see CBC
OFB - see CBC
CTR - decent, but lacks integrity and authentication
XTS - used only for disk encryption
*Authenticated encryption below*
OCB - ?
CCM - CTR w/ CBC-MAC, ?
CWC - ?
EAX - ?
GCM - decent, however there might exist attack vectors using weak keys, biclique attacks, etc.
SGCM - same as GCM except that weak keys are no longer a threat because GF(128) is not used
Modes such as (S)GCM and CTR use a nonce instead of an IV (which is used by CBC, etc.). The difference between a nonce and an IV, except for the fact that they are both required for the mode of operation to perform the initial encryption/decryption, is that the former only needs to be unique whereas the latter needs to be unique AND random or pseudo-random at least.
Indeed, if you use the same nonce for different encryption operations with GCM, then forgery becomes a possibility for the attacker. This is catastrophic. With an IV though, if it is not random enough, an attacker may be able to determine segments of the plaintext based on the ciphertext.
With that in mind, I would rather use a nonce-based mode of operation. Why ? Because I no longer have to trust my RNG not to be flawed. I just have to make sure the nonce is used once and strictly once. So finally, GCM seems to be a safe bet. It is widely adopted as a AE (Authenticated Encryption) mode of operation.
However, it is recommended by NIST so it may be badly flawed or NSA might have ways of weakening its security.
What do you guys think ? What's your preferred mode ?
[1] https://www.youtube.com/watch?v=v0IsYNDMV7A
Fuck, this looks impressive, but I'm 10/10 that no one here can contribute intelligently.
Good luck!
>>53366943
I hope you're wrong
thx m8
shameless bump
>>53366608
Nice thread OP, but my crypto knowledge is basic at best. I recently reaf a blog post about telegram's encryption with some interesting comments, I'll post it
>>53367983
Found something more relevant from the same blog, check this out
http://unhandledexpression.com/2015/10/01/crypto-problems-you-actually-need-to-solve/
>>53366608
NSA isn't necessarily bad when they suggest things when it comes to crypto, they suggested a specific S-box for either DES or AES that made it srong against some side channel attacks before anyone even considered those to be a thing
>>53366608
I think you're a bit quick on discarding first ones (as I expect you need this for an essay or paper or something). I must say that I haven't really looked into modes of operation for a while as I'm more of a math guy and am more into homomorphic and ZKP, but here's some thoughts:
- CBC is standard so guess I'd use that.
- I didn't watch the video (its a bit late here plus and its kinda difficult to take guys like this without a paper as a credible source for me) but even if they are right CFB still has practical advantages over CBC.
- PCBC is kind of obscure I haven't really seen it used recently. I think I remember it has a flaw with the blocks or something.
- CTR is really nice, mostly because its the 'simplest' one that gives you random access. I think your reasoning about nonces is right except that you're saying "I can't trust RNGs" while there are really okay ones out there.
- XTS has the same flaws you list for CTR. You could look into EME as, while being practically unusable, sounds pretty good crypto-wise.
>>53368169
This.
Also, where an algorithm or technique comes from should not matter (inb4 nice try nsa), people should focus on the technique itself and proofs instead: if the algorithm was studied carefully it would never have accepted in the first place.
Here's surprisingly well-written essay about the NSA's involvement in crypto
https://eprint.iacr.org/2015/1018.pdf
Glad to see there are many good replies. It's late here, so I'll make sure to respond in the morning.
Have a good one /g/uys
>>53366608
This is actually a really good thread OP, congrats.
I'd love to contribute but my knowledge of cipher block modes is very basic. Will definitely be lurking though.
Is there a backdoor in Rijndael? I've moved away from it as much as possible.
>>53366608
>it is recommended by NIST so it may be badly flawed or NSA might have ways of weakening its security
Literally just ignore what NIST says about everything. "NIST says it's good" isn't evidence that it's actually good anymore (because of NSA shilling), but it's also not evidence that it's bad. Just ignore their bullshit in favor of more reliable sources.
>>53369366
I've never heard of anyone knowledgeable proposing such a thing.
What did you move to?
>>53369366
>>53369504
There is a hypohesis that the MixColumns stage leaves a structure in the cyphertext that can be exploited due to the nature of linear transformations but nobody has been able to prove insecurity. I would trust it.
>>53369469
The other 15-ish curves from that same NIST recommendation actually came with a reasoning as to how the parameters were determined (and it would be massively difficult to come up with parameters that were both pre-computed and reasonable, if such a pair even exists), it was only the last curve that had NSA-recommended values that looked 'arbitrary' but then, see >>53368169 the NSA actually mitigated attacks and the people trusted them.
It is only the FIPS requirement [1] of the "NSA Curve" that raises suspicion to them as an organisation but these are made by the government itself and not the scientific community.
[1] https://en.wikipedia.org/wiki/Dual_EC_DRBG#cite_note-14
>>53369649
Not same guy, but would you maybe have a pdf on this? Kindof hard to google when you put it like this
>>53369366
Snowden docs say the NSA was looking for it. Which would indicate they didn't have it back then.
>>53369881
>Not same guy, but would you maybe have a pdf on this? Kindof hard to google when you put it like this
Sorry don't have source, one of the lecturers on the Crypto unit I am taking mentioned it. I don't think they are bullshitting since the Crypto group here is one of the best in the world. Maybe it was something passed around between some researchers or something but not something worth writing a paper about.
>>53369469
NIST says they can't read the leaked docs about the subversion cuz they don't have clearance. In the dustbin they go.
>>53368038
I've check some of the other posts on his blog and it's high quality material, thanks for sharing.
And yes, Telegram sucks because of many reasons. Signal should be used instead, as Moxxie was/is behind it.
>>53368169
Surely they have innovated new concepts that were good and they will continue to do so, thanks to their budget, but I wouldn't take all their work for granted. I'd take time to scrutinize it,
>>53368516
Actually I'm writing a program that features encryption, and unlike 90% of the rest of the developers who just say "we'll encrypt it with military grade AES 256" I'm trying to really understand all of it so that the crypto part is as secure as it can get.
If you've got time and Java installed, check it on GitHub Serphentas/CryptoClient
As for modes of operation:
CBC - it may be, but it needs padding and that is one more hassle. CTR effectively get rid of that.
video - seeing it's from DEFCON, I assumed these guys aren't spouting bs but they might be wrong on some points, idk
CTR - TRNGs might be reliable, but most of them are proprietary (or have a very slow seed rate if open source/hardware); PRNGs are mostly good in theory, but considering the fact that some hardware TRNG such as Intel's are flawed by design, the seed that PRNGs feed upon might render the output not as random as we'd like it to be (but not deterministic either)
XTS - idd, double pass seems like too much complexity for a practical implementation.
Talking of proofs, I have some PDFs regarding GCM. Gotta upload them, gimme a moment.
Will read, thanks.
>>53369264
lurk moar
>>53369366
Pure Rijndael != AES, as they made some changes in the final version of Rijndael that is now known as AES.
Regarding backdoors, there are none. However, some attacks exist but are too expensive in resources to be practical.
I, too, wanted not to use it in favor of other ciphers such as Twofish or Serpent, but then I realized it's the only one cipher that gets the most attention
cont...
>>53374353
the most attention from every cryptanalyst around the globe (unlike others). Therefore, it is the most secure in that it is the most tested. You can use some shady cipher nobody knows shit about, but then it might be easily crackable because no peer has reviewed it in the past.
tl;dr stick with popular ciphers
>>53369469
see >>53374353
I'll send you reliable sources (PDF) in just a moment
>>53369881
Although I'd like to use (EC)DSA, some suites seems to be flawed by design. I'd stick with Curve25519 instead, even though some clients may not support it in TLS.
>>53372026
topkek
>>53374353
You can access those files I was talking about in whitepaper/crypto at theswissbay . ch / pdf
>>53366608
I agree that AEAD w/ GCM is probably the best choice right now if you have to pick a mode, but I'm partial towards stream ciphers.
A good stream cipher with an absurd number of iterations (say, Chacha20/1024) will be practically unbreakable for a very long time, at reasonnable performance.
Any good crypto books for a newbie?
>>53366608
>What do you guys think ? What's your preferred mode ?
I use AES in GCM mode because it's authenticated, fast, and generally supported out of the box in all the software I use.
What is your target application and threat model? That seems like a pretty important part you left out.
>>53375467
Schneier's Applied Cryptography is pretty good, I'm halfway through it.
>>53368516
>- CBC is standard so guess I'd use that.
Good job on choosing what's basically the least secure cipher mode on that list.
>>53375497
Nigga please, ECB is on that list.
>>53375487
The use case is general purpose file encryption. That is, with a given program, you can encrypt any file you want and access it at a later time.
Threat model: mostly trying to make MITM useless, so that live decryption and later decryption (after storage via MITM) are impossible.
see Serphentas/CryptoClient on GitHub, that's what I'm working on right now. I want to provide online file storage, just like Dropbox does, but fully encrypted client-side.
>>53375502
Yes, ECB and XTS are even worse but who in their right mind would use those for transmitting network data? I'm not even sure I'd consider ECB as technically qualifying for a “block cipher mode of operation”.
Of the ones that are actually used in the real world, CBC has proven the worst in terms of security. It just has so many attack vectors.
>>53375525
>The use case is general purpose file encryption.
With or without needing to re-encrypt the entire file every time you make a 1-bit change?
Also, if I had to come up with a system like that, I'd personally just use GnuPG - since it's proven itself on practice on more than enough occasions to be reliable.
Something my homebrew crypto probably won't be.
>>53375541
>GnuPG
The problem with GnuPG is that (unlike symmetric block ciphers) it will be completely broken as soon as attackers upgrade to quantum computers.
Given that >>53375525 wants immunity from “later decryption” it seems pretty important to avoid anything that's weak to Shor's algorithm.
>>53375525
>I want to provide online file storage, just like Dropbox does, but fully encrypted client-side.
Look into what the SpiderOak people are doing with ZK crypto, it's a whole new level of subpoena-proof
>>53375552
If you assume quantum computers, there is nothing useable today, except maybe AES256 with some horribly innefficient and poorly studied PQ signature scheme.
>>53375541
In the code on GitHub, you can see that for each encryption operation a key and nonce are generated. So yes, the whole file would have to be re-encrypted.
I might implement a feature that does not generate a new key/nonce pair if the file that's being encrypted has not changed.
>>53375592
>If you assume quantum computers, there is nothing useable today, except maybe AES256 with some horribly innefficient and poorly studied PQ signature scheme.
I wasn't aware of e.g. HMAC-SHA512 being weak to quantum computers.
>>53375610
Hm, yeah you might be right, I though HMAC was broken but apparently it's not (only Grover applies).
>>53375636
this article might be interesting regarding hash functions, though I need to read it again to understand some concepts
blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
>>53375676
Thankfully we have solid hash functions like keccak that are not vulnerable to this. Can't trust the application developpers.
>>53375564
From what I've seen, they use js for their clients, so yeah...
>>53366608
OCB is good but patented (there's a GPL patent grant). CCM is slow. I never really looked into EAX.
GCM-SIV is a nonce-reuse resistant variant of GCM. Still very new.
ChaCha20-Poly1305 is better overall, especially if you dont have hardware support, so you don't have to worry about possible side channels from AES implementations; Poly1305, as a Carter-Wegman MAC, is an information-theoretic secure authenticator.
Again, never reuse your nonces. That way lies non-theoretical disaster. Sequential nonces work best (random nonces you start worrying about collisions and possible attacks related to those), ideally if implicit in your protocol.
Look into the CAESAR competition too. I like NORX. AEZ is also popular.
Always hash your protocol transcripts. Makes the proof so much easier... you do have a proof in ROM or standard model, right?
>>53375698
Pity Keccak performance sucks in software (not that NIST ever gave a fuck about software). That's why I'm using the superior BLAKE2.
GCM is actually a fairly secure cipher mode, and it's only weakness is collision attacks after encrypting 64gib of data.
>>53377027
Woops I meant OCB. OCB is my personally preferred cipher mode; the only problem with it is that it is patent encumbered.
