
When AES(☢) = ☠ – a crypto-binary trick  - ange4771_
https://speakerdeck.com/ange/when-aes-equals-episode-v
======
aidos
That was a great read. I saw the title and figured it would quickly go over my
head but it's all pretty understandable.

Does anyone know where I can download the src to have a look through?

Edit: found it
[https://code.google.com/p/corkami/source/browse/#svn%2Ftrunk...](https://code.google.com/p/corkami/source/browse/#svn%2Ftrunk%2Fsrc%2Fangecryption)

~~~
ttflee
The play of unicodes reminds me of some awesome slides made by Larry Wall and
other Perl hackers. A good slide show is about to convey messages in a
visually efficient and succinct way, not in an overloaded and bloated one.

------
drdaeman
There's also a word play in the title. "AES" transliterates to "АЭС" (acronym
for " _А_ томная _Э_ лектро _с_ танция") in Russian (and some other Slavic
languages), which means "nuclear power plant". Thus, the "☢" sign.

~~~
ange4771_
that's totally unintended: I just looked for some interesting unicode
characters and chose these 2 for the video game references ;)

------
mooism2
Actual link: [https://speakerdeck.com/ange/when-aes-equals-
episode-v](https://speakerdeck.com/ange/when-aes-equals-episode-v)

------
silsha
Recording of the talk:
[http://podcast.raumzeitlabor.de/#wbHkVZfCNuE](http://podcast.raumzeitlabor.de/#wbHkVZfCNuE)

------
krick
That's amazing. Didn't think it's even possible, however it turns out to be
surprisingly simple. Also, laughed out loud because of that guy's twitter
nickname on the 3rd slide.

------
dikei
Cool trick, I have encountered something like this in a steganography wargame
before, the only difference is they used Base64 encoding on the original
picture instead of AES :)

~~~
yiedyie
Base64 is not true encryption, it doesn't require a key it is merely
obfuscation.

~~~
georgemcbay
In the general usage case base64 is not even obfuscation, really (though it
does make it non-human-readable... for most humans), just an encoding for
dealing with situations where you need to store or transmit 8-bit or multibyte
character data into a system that may otherwise be incapable of dealing with
it reliably.

------
reblochon
Does any one know the name of the hex editor used in these slides, the one
showing the PNG chunks and JPEG information?

~~~
ange4771_
that's
[https://bitbucket.org/haypo/hachoir/wiki/Home](https://bitbucket.org/haypo/hachoir/wiki/Home)

------
JoachimS
A good example of why a MAC after encryption is also needed. And blocking
length extension attacks.

~~~
tptacek
Where do length extension attacks come into play with angecrypt?

------
thristian
I love the "HexII" hex-dump format he links to, it's so much less cluttered
than the traditional one. I'm definitely going to have to try that out the
next time I'm picking apart some binary file.

~~~
ange4771_
thanks - HexII is in very early development for now.

------
hzc
this is awesome. now I hide secret information in a seemingly innocent image.
no one would want to use AES to decrypt it if the image looks fine.

------
ShowNectar
Where do you store the IV? Do you just append it at the end of the file?

~~~
mzs
You have to supply that, see the python script, at the end it prints what to
run to decrypt, the determined IV is passed as a param:

[http://corkami.googlecode.com/svn/trunk/src/angecryption/ang...](http://corkami.googlecode.com/svn/trunk/src/angecryption/angecrypt.py)

------
glial
What's the benefit of AES using such small blocks?

~~~
AnthonyMouse
The block size of a symmetric cipher will generally be in the neighborhood of
the key length. You can imagine the problem if you had a 128-bit key but an
8-bit block size -- for each of the 256 possible inputs you would have only
256 possible outputs. There would be multiple keys that produced the same
mapping and you could produce every possible mapping with only 65536 keys. So
the block size needs to be near the key size. Making it larger than that
wouldn't make it any more secure but would make it slower.

~~~
tzs
This doesn't sound right to me. There are 256! permutations of the set {0, 1,
2, 3, ..., 255}. 256! is much bigger than 2^128, so I see no reason that each
key cannot produce a unique mapping.

> So the block size needs to be near the key size

Note that AES-256 has a 256 bit key, but the block size is 128 bits, which is
not near the key size.

I believe that the main constraint on block size is that a small block limits
the length of messages you can safely encrypt with a given key. If the bad
guys see a lot of cipher text encrypted with the same key, they have a better
chance of a successful attack. What "a lot of cipher text" means depends on
the block size. The bigger the block size, the more cipher text is needed to
constitute "a lot of cipher text".

~~~
tptacek
A smaller block also gives you less room to maneuver when designing modes of
operation; for instance, it can be tricky to implement CTR with a 64 bit block
--- the convention is to split the block into "counter" and "nonce", and you
need enough space for the counter that it can't conceivably wrap.

~~~
Tomte
This may be a stupid question, but why is there a convention to split?

I saw that in set three of the crypto challenge, as well, and wondered.

Is it so that you can always start counting at zero when re-starting the
application, as long as you're randomly picking a new nonce?

And if you just picked a random counter value at each restart you might get
very unlucky and at some point reuse a counter value, so by this convention
you're separating counter values belonging to different restarts?

~~~
sdevlin
Conventions and usage vary by setting, but yes, it's to prevent nonce reuse.

A typical scenario might use a single encryption key for many different
messages. A simple strategy is to allocate 64 bits to a message counter and 64
bits to a block counter. For each encryption you can increment the message
counter by one. The block counter starts at zero and increments for each block
of the message.

Note that this imposes hard limits on both the number of encryptions you can
perform with this key (2^64) and the number of blocks a message can contain
(also 2^64). As long as we respect these limits, we're guaranteed never to
reuse a nonce.

If we use a random 64-bit nonce in place of the message counter, the picture
changes a little. Due to the birthday paradox, we can now expect a collision
in around 2^32 encryptions, which is a little close for comfort.

Fortunately, we can tune the bit allocations based on the needs of the
application. So a reasonable strategy might be to bump the random message
nonce to (say) 96 bits and leave 32 for the block counter. This still allows
individual messages of around 64GB.

Of course, parameters like these should be considered implementation details
for 99% of application developers. The best thing to do is to use a high-level
library like NaCl that makes reasonable choices and then abstracts them away.

------
BrokenPipe
impressive! a very cool hack!

------
frik
Impressive.

That's also the reason why one should limit the max-length of a password field
(something reasonable), if one is using the _salted-password in db_ approach.
Otherwise someone could enter a very long password to do the trick (MD5/SHA1),
see
[http://en.wikipedia.org/wiki/MD5#Security](http://en.wikipedia.org/wiki/MD5#Security)
.

~~~
jimktrains2
I guess I'm not following your logic. If there is a salted, hashed password in
a db, allowing arbitrary length passwords shouldn't matter? HMACs and KDFs
work very differently from symetric-crypto primatives.

~~~
michaelmior
The point is that it makes it easier for an attacker to find a hash collision.
It's much easier to construct data which hashes to a given value if it can be
of arbitrary length. I don't immediately see the connection with this article
however.

~~~
asdfaoeu
I don't follow. Breaking a password hash your not trying to find a hash
collision you need to break the preimage attack. Sure are some stage in the
future there might be a preimage attack that requires a large amount of data
to use. But really if your worried about theoretical preimage attack you
aren't using md5.

