[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dcms-dev
Subject:    [opencm-dev] OpenCM Security Level Revisited...
From:       "Jeroen C. van Gelderen" <jeroen () vangelderen ! org>
Date:       2003-05-03 18:44:48
[Download RAW message or body]


This has been discussed before but I've never documented my desire for 
use of SHA-256. This note fills that void. It is written from memory 
with regards to OpenCM details as I'm travelling. Please don't nitpick 
:)


The NIST draft "Special Publication 800-57, Recommendation For Key 
Management" [1] sets guidelines for key management in government 
applications. When it is approved and published it will likely become 
mandatory in industry and government alike. This will affect OpenCM 
adoption in these areas.

According to [1] (page 98) applications offering 2^80 security are 
sufficient from the present to 2015. Between 2015 and 2035 a minimum of 
2^112 is required. After 2035 the requirement is 2^128.

OpenCM uses a variety of cryptographic techniques, some of which are 
easily upgraded and some of which are not. Access control mechanisms 
fall in the former category whereas the persistent entity hashes fall 
in the latter.

OpenCM presently uses SHA-1 for its entity hashes. As these entity 
hashes are subject to birthday attacks they yield about 80 bits of 
security. According to [1] this is sufficient until 2015. After that 
date the hash function must be replaced, preferably with SHA-256.

By sticking to SHA-1 now OpenCM is setting itself up for a Y2K problem. 
OpenCM should switch to using SHA-256 for its entity hashes before a 
general release, rather doing this after it has seen significant 
deployment. This is especially sensible since use of SHA-256 is not 
significantly more computationally expensive.

The OpenCM team should also document this decision and publish the 
rationale so as to encourage others to take the same approach.

NOTE: 128-bit Swiss numbers should be used too but I think that already 
is the case.

NOTE: The repository authentication key is relatively easily upgraded. 
However it may be advisable to use a 2048 or 3072-bits key by default. 
Unlike the immediate adoption of SHA-256, a larger repository 
authentication key does pose significant computational requirements on 
the client and server. Given that use of this key is not in the fast 
path, a 3072-bit default may yet be sensible provided it can be 
overridden.

NOTE: My personal (professional) opinion on selecting key sizes would 
err slightly more on the conservative side. This would not affect the 
choice of hash function (still SHA-256) but rather require a minimum of 
a 1536-bit repository key [2] at present. If a 3072-bit default is not 
realistic, I would advise considering a 1536-bit default which gives me 
a warm, fuzzy feeling until 2013.

-J

[1] http://csrc.nist.gov/CryptoToolkit/kms/guideline-1-Jan03.pdf
[2] http://www.simovits.com/archive/cryptosizes.pdf
-- 
Jeroen C. van Gelderen - jeroen@vangelderen.org

"Be precise in the use of words and expect precision from others"
                      -- Pierre Abelard

_______________________________________________
opencm-dev mailing list
opencm-dev@smtp.opencm.org
http://www.opencm.org/mailman/listinfo/opencm-dev
[prev in list] [next in list] [prev in thread] [next in thread]