Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
От | Peter Eisentraut |
---|---|
Тема | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 |
Дата | |
Msg-id | 6c2c2c7f-8666-7105-0942-f35176a73c62@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
|
Список | pgsql-hackers |
On 2020-09-24 21:44, Daniel Gustafsson wrote: >> On 24 Sep 2020, at 21:22, Robert Haas <robertmhaas@gmail.com> wrote: >> >> On Thu, Sep 24, 2020 at 1:57 PM Peter Eisentraut >> <peter.eisentraut@2ndquadrant.com> wrote: >>> Depends on what one considers to be covered by FIPS. The entire rest of >>> SCRAM is custom code, so running it on top of the world's greatest >>> SHA-256 implementation isn't going to make the end product any more >>> trustworthy. >> >> I mean, the issue here, as is so often the case, is not what is >> actually more secure, but what meets the terms of some security >> standard. > > Correct, IIUC in order to be FIPS compliant all cryptographic modules used must > be FIPS certified. As I read FIPS 140-2, it just specifies what must be true of cryptographic modules that claim to follow that standard, it doesn't say that all cryptographic activity in an application or platform must only use such modules. (Notably, it doesn't even seem to define "cryptographic".) The latter may well be a requirement of a user or customer on top of the actual standard. However, again, the SCRAM implementation would already appear to fail that requirement because it uses a custom HMAC implementation, and HMAC is listed in FIPS 140-2 as a covered algorithm. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: