Honey Encryption | Hacker News Reader

Honey Encryption

en.wikipedia.org

75 pointszerognowl11 comments

Hmmm. This is pretty interesting. I could imagine doing the same with pre-written out messages too. Write two messages, one real with a stronger key or password, one with a weaker one. It would allow you to not only stop the brute force, but also give Eve bad intelligence.

It's similar to https://en.wikipedia.org/wiki/Deniable_encryption but a lot more rigorous and well thought out

Just FYI - some people[1] have expressed rigorous ideas about deniable encryption, too!

[1] http://eprint.iacr.org/2013/454.pdf

Well, that sucks. The paper appears to be paywalled by IEEE[0]. Are there any freely-available references to this work?

Edit: Eureka! A pre-pub version on the page of the other author http://pages.cs.wisc.edu/~rist/papers/HoneyEncryptionpre.pdf

[0] http://ieeexplore.ieee.org/document/6876246/

IEEE papers are also on sci-hub.cc

Interestingly this website is blocked on many corporate networks as "unethical" or "illegal".

What's "interesting" about this? The entire website is massive copyright infringement. It's extremely useful for researchers, but if you're going to the trouble of filtering and blocking content on a corporate network for legal reasons, isn't this exactly the type of website one would block?

While this is interesting, what effective bruteforce techniques are there against currently used encryption?

Even 3DES is still likely to be secure against all but state actors.

Mind you this can't be used with hashing since this effectively be a collision (could possibly be used with salt poisoning and potentially with variance in rounds).

> Even 3DES is still likely to be secure against all but state actors.

Not if my passphrase is S3cur3!. The primary use case for HE is securing data that's encrypted with keys that a human chose.

If you are attacking pass phrase key derivative algorithms then it usually doesn't matter what encryption you are using unless it's something that was intentionally designed to protect passwords and is punitively slow.

This could potentially work but the problem is that KDA's are used to generate KEKs usually not to encrypt the actual data.

It also remains to be seen of this has an impact on the strength of the key especially for chosen plaintext attacks.

It all depends on the implementation. In some implementations the plaintext is still revealed even with an incorrect key, and so more than likely the cracker sees random noise. The Honey technique, of course, gives plausible looking plaintext to fool the cracker.

Not forgetting you can just slow a brute force session down by punishing multiple attempts.

Reply on news.ycombinator.com