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.
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.
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.
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.
[+] [-] userbinator|9 years ago|reply
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|9 years ago|reply
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|9 years ago|reply
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/
[+] [-] dozzie|9 years ago|reply
> 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.
[+] [-] JoachimSchipper|9 years ago|reply
[+] [-] jdc|9 years ago|reply
http://www.softether.org/
[+] [-] revelation|9 years ago|reply
https://youtu.be/qjBHTS6BKX4?t=5m36s