[Cryptography] Checking for the inadvertent use of test keys

[ianG]

On 4/09/2015 05:03 am, Tom Mitchell wrote:
>
>
> On Thu, Sep 3, 2015 at 3:22 PM, Christian Huitema <huitema at huitema.net
> <mailto:huitema at huitema.net>> wrote:
>
>     > On Thu, 9/3/15, Peter Gutmann <pgut001 at cs.auckland.ac.nz <mailto:pgut001 at cs.auckland.ac.nz>> wrote:
>     >
>     >  So for now I've left things at the ad-hoc level, checking
>     >  for ASCII strings,
>
>     .....
>     >  user "are you sure this is what's meant to be used as a
>     >  key".
>
>     You could consider using machine learning. Get a good sized sample
>     of test keys, an equal size sample of no test keys, constraint the
>     learning enough so that it does not simply enumerate the test keys,
>     and you would get a nice little classifier that would tell you
>     whether to trigger the question.
>
>
> One important bit is how to structure this in your code.
> Even if you have no strategy today the code stub can
> return all-OK or randomly trigger a user check.
>
> You do want to carve out an interface that identifies data,
> data flow,  security policy and friends even if it is unclear
> what to test for at this point in time.
>
> I say this in part because a learning strategy has to remember some
> things that might be considered secrets.
>
> The stub may start as a block of code that lists things to do correctly
> and tests
> that each has been done.
> Static answers get optimized by compilers and can vanish but continue
> to establish documentation and criteria long after you move on and someone
> else is tasked with maintaining the code.  asserts() qualify but if
> DEBUG is
> never defined as true they never tell you anything.
> Pick a cat, any cat and ask Schrödinger


This is becoming a good argument not to do this in Peter's code.  It 
will never do what is wanted to any strong degree, and will invoke all 
sorts of visions for improvement.  Until that day when someone dicovers 
a very cunning hack, and the wrong sort of fame starts knocking.

Kick it up the stack.  Make the caller deal with it, or carry the 
consequences.



iang