OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ekmi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ekmi] Re: [P1619-3] OASIS EKMI Article in InformationWeek




Arshad Noor wrote:
> Legacy data issues are always a legitimate concern in any environment,
> Allen.  However, I believe that the problem will be addressed rather
> differently than in the way you suggest.  Here's an analogy of how I
> think it will happen:
> 
> Currently, there is a recommendation from NIST that all software/data
> that use SHA-1 should migrate away from this digest by the end of 2010.
> How do you think most people will accomplish this?  They will likely
> modify their applications/data to use one of the newer Suite-B message
> digests rather than preserve the old SHA-1 data and perennially have
> doubts about the integrity and veracity of that data because of the
> de-listed hash.

Actually I don't think this will be done at all as the amount of 
work to roll the digests over millions of files without any 
commensurate ROI will cause the enterprises to cheap out. That is 
the behavior I have seen, and is exactly what happened with the 
CitiBank ATM breach as well as Wells Fargo for older (in the sense 
of having been customers a while, not actual age of the client) 
customers.

They will likely say that the tapes (or whatever) are stored in a 
protected vault and so need no additional protection. That is what 
WF has done about encrypted their databases.

> Similarly, an application that uses 3DES or AES today will continue to
> use it until new recommendations are made in the crypto community.
> When the recommendations are made, there will be a transition period
> during which application developers and security officers will have
> the time to migrate their data and infrastructure to use the newer
> algorithms.  When done, they will turn off the older algorithms by
> not making them available in any KeyUsePolicy (in an SKMS).  However,
> an SKMS, for the duration of the transition, will continue to support
> both sets of algorithms, digests, etc. until the last KUP using the
> older algorithms is turned off.

Hope ever, hope on. I haven't seen that to date so I'm very 
skeptical that it will ever happen.

> Not only does this obviate the legacy issue, but more importantly,
> it eliminates the concern that there is ciphertext lying around in
> the company's infrastructure that may be encrypted with a "weak" or
> "broken" algorithm.  That will be a bigger danger for companies
> trying to manage risk in this new world of IT regulations.

Given the response of a variety of companies to being breached I'll 
believe it when I see it.

Best,

Allen


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]