
Cabinet of curiosities: A bunch of cryptographic protocol oddities - bjornedstrom
http://blog.bjrn.se/2016/08/cabinet-of-curiosities-bunch-of.html
======
userbinator
_He also seems to be the only one who has a soft spot on using little endian
representations of integers in his cryptographic designs. This in a world that
is largely dominated by big endian protocols._

The middle and lower layers of the network stack are historically big-endian,
and the ones published as RFCs also tend to be the same, but I've seen many
more proprietary little-endian application-layer protocols. That's probably
because most systems are LE today and so it's simpler overall to read into
memory and operate directly on the values without having to reconvert them,
but in crypto there is a real benefit in working with multibyte integers,
since carries propagate forward.

~~~
rdtsc
Yeah, I've designed some and seen some designed which are LE. There were
mostly newer and all used where latency performance was very important.

I saw one working group designed a protocol such that the serialiazation
format was equivalent to how gcc on 64 bit, intel linux machineas would pack C
structures.

This was of course never mentioned in the official description, as it was
supposed to be architecture/compiler/machine neutral, but I kept wondering why
the odd padding here and there, and then it dawned on me.

So if someone was going to play fast and loose, they could just simply cast
packet data directly to a C struct. If anyone happens to have a different,
compiler / architecture / etc they'd have to jump through hoops a bit
inserting seemingly awkward pad bytes and do le-to-be conversions.

------
noinsight
IPsec is indeed an odd protocol in that it's almost too flexible, but I think
that was probably inevitable - it's part of the TCP/IP suite after all. The
various vendors probably wanted support for all kinds of weird scenarios
built-in.

That doesn't make it particularly good, however. I've looked at it a few times
in hopes of implementing my VPN's with it, and there doesn't seem to be any
simple intelligible documentation on how to implement it with the basic Linux
/ FreeBSD tools. It feels like getting into birdwatching with all the
different Swans and the weird jargon. Until now, OpenVPN has prevailed.

I'm hoping WireGuard [1] will get widescale support soon enough.

[1] [https://www.wireguard.io/](https://www.wireguard.io/)

~~~
dozzie
Add to IPsec the fact that it was cryptography developed under US export
restrictions. This is probably the reason why it has AH for data integrity and
ESP for data protection and/or, well, integrity, rendering AH actually
excessive.

> Until now, OpenVPN has prevailed.

Which is somewhat funny, as FreeS/WAN derivatives are much more convenient to
configure than OpenVPN with its tons of options that you need to put either on
server side or client side (and those differ greatly) and routing that is
very, very easy to screw up.

Also, I always say that OpenVPN is a weird case of a program open source from
the ground up that has a closed communication protocol. No specification and
extracting the protocol from the source is difficult in this case.

------
revelation
There is this great presentation on MS-CHAPV2:

[https://youtu.be/qjBHTS6BKX4?t=5m36s](https://youtu.be/qjBHTS6BKX4?t=5m36s)

