oss-sec mailing list archives

Re: CVE assignments for "weak" crypto (was CVE Request: MD5 used for Download verification)


From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 13 Mar 2013 19:51:46 -0600

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/12/2013 09:36 AM, Christey, Steven M. wrote:
All,

This is an informal response, but I wanted to get something out
pretty quickly.

For CVE, our default position is that "using MD5 for integrity
checking of downloads" is a security-hardening issue, and thus
should NOT receive a CVE ID.  While MD5 may be "broken" from a
theoretical standpoint, and there have been some demonstrations of
collisions, and stronger options exist - I do not know of any
reliable means of efficiently generating a collision that would
also remain a functioning executable.  There is also a strong
likelihood of debate as to which method is currently "strongest."

This is timely:

http://cr.yp.to/talks/2013.03.12/slides.pdf

one quote:

2012.06.07 Stevens: "A chosen-
prefix collision attack against
MD5 has been used for Flame.
More interestingly ... not our
published chosen-prefix collision
attack was used, but an entirely
new and unknown variant."

CrySyS: Flame file wavesup3.drv
appeared in logs in 2007; Flame
"may have been active for as long
as five to eight years".



- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBAgAGBQJRQS0yAAoJEBYNRVNeJnmTDrgQANAgBLsmerQmvSEfkw8uxzKv
6tuooZs7/mZqhr1JzLu4IBndjqx+z4UyvRP+qSNJDbchUDO/LsZMItKXh3QzPQec
dLBumidg2HorCseFhZev8C9MCRRzNPcH2N9BGdnE18C1gh5Ukv9Ks8IMLbH7vGDc
LfB62ph8CvVawyfmC7WNfUpk+Nxi0GyRPcD0dGxjz6aSqMflqudMsDUM/D5yCmL8
Oyyj84IbMsH0zMcS3s7UhGgE7rzIN5u/0MS+fl+wFwDsq/7KR7gCyZ0RJ8+2S48R
THWtATLD51b4PzDfZ/blzU3XUosPjVT1MY/66+ScOEfe8BAIXlZ2bYSVgUR5/T9L
hP8+aqP7tCAzfSsrDTCjla5e16w7vClED3PQxGndpfxioVsgjgqLnqDQ6gDb2Ceo
er+igl/JCA7KY3+OaItZ3l2oRBe3gbne5n3LTxa22t/pKVYyoBaxR5I3ht6hPMP9
JFLQDj/B5BKMXT2iGoNR9POvukrQ2vx8MfaNBUwXxqu+Ja4XJ4kK67gs7Z1bAIRX
Kq8CjYmLzBQozA9zapJOI5sHNHSEkPiU4NG+Wal+6T+nj+OORBVjnwE1+jCss485
1uECwLOavdUBoMtiJfuTTNo5BkGj1euioKua2v5zdMemgpEeERPagmbxcMjNBJuJ
Sl8BK2W8RdNncCor7yqZ
=LnRh
-----END PGP SIGNATURE-----


Current thread: