[Cryptography] Heartbleed and fundamental crypto programming practices
Bill Frantz
frantz at pwpconsult.com
Sun Apr 27 10:14:51 EDT 2014
On 4/26/14 at 5:10 AM, leichter at lrw.com (Jerry Leichter) wrote:
>ASN.1 was designed at a time when networks were slow and every
>bit counted. It's an *extremely* tight encoding.
I must admit being an IBM architecture fan by reflex. I like
having channels where the memory locations an I/O transfer can
reference are determined in a device independent maner. I'm
always surprised by little endian thinking, even though we big
endian people lost the battle everywhere but the IETF. The piece
of IBM think most valuable for this discussion is records.
IBM systems are built around records while Unix descendants are
built around streams. Records have the advantage that a whole
record is by definition accessible in memory at the same time.
You can put all the fixed length items at the start of the
record. (If you are careful, you can align them on hardware
boundaries for access speed.) There is a attraction to making
data items fixed length if possible, which speeds access, rather
than variable length which generates the parsing problems we
have been discussing.
Of course there are disadvantages too. Input from a sound card
is naturally stream like and breaking it into records is unnatural.
However, more record-like thinking might make data structures
which are less bug prone to parse.
OBSecurity: Note that compressing any data collection which
spans security classes is a serious security flaw.
Cheers - Bill
-----------------------------------------------------------------------
Bill Frantz | If the site is supported by | Periwinkle
(408)356-8506 | ads, you are the product. | 16345
Englewood Ave
www.pwpconsult.com | | Los Gatos,
CA 95032
More information about the cryptography
mailing list