The DMZ

@TomK. The problem is the leakage of information through the size of data as it varies over time. Video compression algorithms will result in smaller payload sizes depending on the contents of the video, which means that some information about the contents of the video will be revealed through size information.

TLS does not add padding to mitigate this.

It's one reason why, for VoIP at least, ZRTP is more secure than SRTP.

Luc

@forest thanks for your comments on my answer earlier! I keep learning new stuff :)

regarding KMAC, is there any reason to use that instead of HMAC except speed? It's secure, no?

forest

11:08 AM

@Luc HMAC is only designed for Merkle–Damgård hashes which are vulnerable to length extension attacks. KMAC is basically just SHA-3(k || m) with a little bit of padding magic. BLAKE2's keyed hash functionality allows a key parameter as well.

So using HMAC with BLAKE2 or SHA-3 as the hash would be a little bit silly.

Q: Is HMAC needed for a SHA-3 based MAC?

HMAC does nested hashing in order to prevent Length Extension Attacks. Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC? Needless to say we'd still use a key, which we prep...

Q: How secure would HMAC-SHA3 be?

It would be possible to implement the HMAC construction with (draft) SHA-3, leading to HMAC-SHA3-224, HMAC-SHA3-256, HMAC-SHA3-384, HMAC-SHA3-512 (the last 3 digits are the output size $\ell$, where $\ell/8$ is the $L$ parameter in HMAC). All that's missing to apply the familiar $$\text{HMAC}_K(\...

hmac sha-3 keccak

For whether it's needed, and whether or not it would be secure if done anyway./

Luc

11:35 AM

alright. I knew that HMAC primarily was against length extension attacks, but wasn't sure if it does more than that so I generally just assumed it was good practice to use with any hash function

Since the author specifically asked for HMAC, I'll leave it in my answer though: it's secure and not significantly slower, and I feel like it'd be counter-productive to shake up their understanding of how hash-based MACs are to be constructed. But it's definitely a good point, so I'll add a note for those who do want to dive deeper into the topic

forest

I'd just specify that it works with any hash and use SHA-2 as an example.

Though HMAC is also totally fine with SHA-1 (and even MD5).

It's just a little weird to use two examples which HMAC is not designed for.

After all, SHA-2 is still quite secure. :)

Luc

I learned yesterday that HMAC with MD5 is still perfectly fine, but it reeks so I figured I'd not recommend that :P. Similarly, given that SHA-3 and BLAKE2b are not vulnerable to something SHA-2 is vulnerable to, and that they seem to be quite widely accepted by now, I feel like using SHA-2 in answers is (to a lesser extent) the same as recommending MD5

forest

The only issue with SHA-2 is the length extension attack, which is not some cryptanalytic attack that was discovered but a known behavior of the function since its inception. In situations where LE attacks are important (in MACs), then a construction like HMAC must be used. Otherwise, they're just as secure as SHA-3. For a KDF (e.g. PBKDF2-HMAC vs PBKDF2-KMAC), they're even more secure in most situations, since an ASIC cracker has a bigger advantage over software with SHA-3 than with SHA-2.

MD5, on the other hand, is bad even for a Merkle–Damgård hash since it is highly vulnerable to collisions (something terrible for any cryptographic hash function).

Also technically not all of SHA-2 is vulnerable to LE, e.g. SHA-512/256.

Luc

11:54 AM

People will always take algorithm recommendations as "oh this is secure" and run with it. If we stop using SHA-2, one can't misuse it in a vulnerable way when they forget "except when I do this specific thing, then I need to use it differently".

SHA-3 being hardware-optimized is a good point though, I forgot about that property of it. I should look for how big a difference it is, depending on that I might indeed not want to recommend that either (since it's also not great for all purposes)

forest

Unfortunately when dealing with cryptographic primitives, there's never a one-size-fits-all function. SHA-3 (or SHA-512/256) is fine for LE-resistant hashing in general, but for password hashing, you should be using Argon2. I tend to tell people to use reputable libraries instead of cryptographic primitives anyway.

But you're right that SHA-2 is easier to use incorrectly than SHA-3 since the former does not model a random oracle correctly (which people often assume from hash functions). But when it comes to ease-of-use and features, nothing beats BLAKE2.

Luc

Wasn't blake2 also a competitor for SHA3 btw?

forest

No, that was BLAKE.

Luc

ah right

forest

BLAKE2 is like BLAKE but with reduced rounds, removed round constants, slightly different rotation constants, and a few extra features. Also handles salt and IV differently (BLAKE injects it in every round, BLAKE2 uses it only in the initial state).

If I recall, they decided against BLAKE at the time because they were worried that its similarity to SHA-2 (and thus SHA-1, MD5, and MD4, which are really all remarkably similar) was too great. SHA-3 uses the Keccak permutation which is based on a sponge function and totally different concepts whereas BLAKE is a basic ARX block cipher in a HAIFA construction, similar to SHA-2's block cipher in the Davies–Meyer construction. They didn't want major cryptanalytic breaks in ARX to impact SHA-3.

But no such cryptanalytic advances have appeared, so the worry was unfounded.

Not that Keccak isn't a neat construction though. It's helped a lot with research into sponge functions (which are the Swiss Army Knives of cryptography, and really cool).

Luc

12:51 PM

forest, do you teach somewhere and how much do you charge?

forest

1:01 PM

I do security consultancy if that counts (I'm not a professor or anything).

Lowest I charged was something like $20/hr for trivial stuff (helped a friend of a friend configure a secure reverse proxy via a GRE tunnel). Highest was something like $400/hr? But that was when I worked with someone else. That's never been what I got on my own. The rate varies because I like working with sketchier clients (it's just more fun imo), so the market varies. It's based more on negotiation than a fixed rate.

Luc

uh sorry, I was mostly kidding - if you had been a guest lecturer somewhere nearby or had given a workshop that seemed interesting, I would have been interested, but I actually just meant to remark that I find the info you give interesting when I didn't have anything substantive to add :)

forest

lol no problem, I probably just didn't catch it because my brain is fuzzy atm :p

Luc

those sketchy clients sound interesting though, you freelance for them or is that for a company? :P

forest

Used to be with a company. Now it's kinda-sorta freelance (I'm still with a group that helps me find clients, since I'm not the person to go to for e.g. web app pentesting).

Luc

okay nice. Sounds like all the pentesting advantages of a bigger corp without the pain of doing your own sales

mostly at least

forest

1:13 PM

Previous company made secure laptops for governments and businesses going to countries with a high risk of espionage. Helping smaller governments protect from bigger governments was fun, since I hate most bigger governments. :p