[Cryptography] defaults, black boxes, APIs, and other engineering thoughts

ianG iang at iang.org
Sat Jan 4 05:22:44 EST 2014


On 3/01/14 19:11 PM, Bart Preneel wrote:
>>On 3/01/14 10:45 AM, Krisztián Pintér wrote:
>>> ...people only use [stuff] if they have to, to be compliant
>>> with [other stuff]. but then they can't change it, not even the
>>> extraction part (heck, they can't even fix the mistakes in the
>>> documentation, see the case of [messy stuff]).
>>
>> This is a seriously good point.  Defaults are meant to be changed, and
>> are offered as a sort of security feature.  Alternatives are offered
>> as if this makes sense in a security context [1].
>>
>> But can defaults be changed?  The barrier to this is often high, and
>> too high to be realistic or give any security benefit.
>>
>> Two questions, possibly as research topics:
>>
>>     1. How often are security defaults changed?  In any given
>> environment such as OpenSSL, etc.
>>
>>     2.  How hard is it to change the defaults?  What is the mental
>> energy, skill & time required?  How high is this barrier?
>>
>> The result of defaults seems to be that they are poorly chosen [2],
>> end up being the only choice for 99%, and open up an easy attack,
>> DUAL_EC [3].
>>
>>
>> iang
>>
>> [1] http://financialcryptography.com/mt/archives/001461.html
>> [2] http://financialcryptography.com/mt/archives/001450.html
>> [3] http://financialcryptography.com/mt/archives/001446.html
>
>
> One minor advantage of random number generators is that interoperability
> requirements are not so stringent - unless you want to interoperate
> with the cryptanalysis tools of three-letter agencies  :-)
> So switching defaults may be easier.


It's an important point.  In software engineering we want two things of 
our lower-layer cryptoplumbing:

1. to create a black box / tool approach so that we engineers can 
construct the business knowing that the tool does what we expect, and 
can be substituted when it breaks.

For RNGs the interface is pretty simple:

    get(byte[] buf)
    {
        // fill buf with cryptographically secure random data
    }

That's it!  Fantastically interoperable, in general.

2. a standard pattern which we can use to construct a new one, so when 
new particular requirements come up we can throw the task to an intern, 
and say "build this to this design!"  Hence my comments on what this 
pattern is, and what name we give it ... for us engineers, we need a 
codename, just like the NSA and their project names.

3.  oh, and we want a security promise of some sort that is easy to 
think about in software & design...


> By the way: while we have failed badly at (secure) algoritm
> agility, this does not imply imho that it is impossible to make
> (secure) algorithm agility work.


Right.  But.  Software engineering as we know it shows that it is an 
expensive tool that is brittle, can be logically expected to miss the 
target when it is needed, and does not actually solve the overall 
problem of upgrade, which needs to be solved anyway.

It's overshadowed completely by other realities.  Have you noticed how 
the entire world is moving to a much more sophisticated update model, 
typically dynamically, monthly?  If you can do that, you don't need 
algorithm agility as a static tool.

We need to rethink the problem and find a better approach.  Any time 
spent on designing a better algorithm agility is wasted time, but I 
suppose it is better to think about it than actually deploy it...



iang



More information about the cryptography mailing list