[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