On 02/14/2009 07:18 AM, Ben Laurie wrote:
Actually, in my extensive experience of reviewing security-critical
code, this particular error is extremely common. Why does Michael assume
that they probably wouldn't? Because he is steeped in the craft
knowledge around crypto. But most developers aren't. Most developers
don't even have the right mindset for secure coding, let alone correct
cryptographic coding. So, why on Earth do we expect them to follow our
unwritten rules, many of which are far from obvious even if you
understand the crypto?
[1]
http://www.lightbluetouchpaper.org/2009/02/02/hidden-assumptions-in-cryptographic-protocols/
Note that one of the things that FSTC did in e-check (and I did in
x9.59) was specify the fields from existing transport infrastructures
that were used for signing.
Part of this was that standard digital signature processes (along with
digital certificates if necessary) could represent a one hundred times
factor payload bloat ... some past comments about various efforts that
tried to apply knee-jerk application of digital signatures to existing
financial infrastructures ... resulting in two orders of magnitude
payload bloat
http://www.garlic.com/~lynn/subpubkey.html#bloat
One of the side-effects of some of the extreme bloated approaches was
that they actually avoided defining end-to-end protocol ... just defined
a digitally signed operation for flow over the internet ... which was
then stripped off and thrown away at the gateway to the "real" infrastructure.
In any case, as a result, the fields from standard existing financial
transaction was specified for encoding ... that was signed ... and then just
the digital signature was appended to existing formatted message.
At the receiving end, the fields were re-encoded and verified with
the transmitted digital signature.
The issue for FSTC that prompted FSML ... was that at the time, the
encoding standards weren't deterministic (i.e the sender and
the recipient had to use the same encoding rules ... so the signed
encoding and the verified encoding were the same). FSML was then
contributed to W3C and incorporated into the XML digital signature
standard.
in that sense, neither e-check nor X9.59 required a length field
... they just specified all the encoded transaction fields that were
necessary for characterizing a transaction unambiguously.
As an aside ... we didn't particularly come at it from the stand-point
of crypto craft or even security-critical craft ... we came at it
from standpoint of business-critical craft ... where things might
fail in a multitude of ways (some possibly having nothing to do
with security). slightly related recent post mentioning FAA ATC
system:
http://www.garlic.com/~lynn/2009c.html#17 Bletchly Park fires up Big Green-Eyed
Monster
Another example was we did "audits" of RAID disk arrays
... looking for design &/or implementation shortcomings
thatmight result in loss of data.
In the "security" context ... we did some audits where
we identified (nearly trivial) exploits in end-to-end operation
... and were told that wasn't part of the security protocol.
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
