>
> > PS, currently it looks like FIPS mode is broken in the mainline:
> > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg49414.html
FYI, SHA-1 is not a good choice, it is only permitted in HMAC
constructions and only for specified uses. If you need to change
algorithm you should go straight to SHA-2 or SHA-3 based hashes.
HTH,
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > > Hi,
> > > > MD
On Thu, 2021-04-01 at 18:31 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 6:22 PM Simo Sorce wrote:
> > On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > > > On Thu, 1 Apr 20
On Thu, 2021-04-01 at 18:02 +0200, Rafael J. Wysocki wrote:
> On Thu, Apr 1, 2021 at 3:54 PM Ard Biesheuvel wrote:
> > On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
> > > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> > > > On Tue, 30 Mar 20
t) changes the integrity check algorithm from md5 to
crc32. This integrity check is used only to verify accidental
corruption of the hybernation data and is not intended as a
cryptographic integrity check.
Md5 is overkill in this case and also disabled in FIPS mode because it
is known to be broken fo
> return false;
> > }
> > #endif
> >
> > #ifdef CONFIG_X86_64
> > -#define RESTORE_MAGIC 0x23456789ABCDEF01UL
> > +#define RESTORE_MAGIC 0x23456789ABCDEF02UL
> > #else
> > -#define RESTORE_MAGIC 0x12345678UL
> > +#define RESTORE_MAGIC 0x12345679UL
> > #endif
> >
> > /**
> > @@ -160,6 +160,9 @@ int arch_hibernation_header_save(void *addr, unsigned
> > int max_size)
> > rdr->jump_address = (unsigned long)restore_registers;
> > rdr->jump_address_phys = __pa_symbol(restore_registers);
> >
> > + /* crc32 digest size is 4 but digest buffer size is 16 so zero it
> > all */
> > + memset(rdr->e820_digest, 0, CRC32_DIGEST_SIZE);
> > +
> > /*
> > * The restore code fixes up CR3 and CR4 in the following sequence:
> > *
> > --
> > 2.18.1
> >
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
o be FIPS compliant and people
that don't. For people that are required to be FIPS complaint vendors
want to provide the ability to use a single knob (fips=1 at boot) to
turn off everything that is not FIPS compliant.
Disabling algorithms at compile time would not work for people that do
not
e would be called
> "accidental" changes, but sure, it could be changes that are "intentionally"
> made provided that the other side can be trusted to not try to avoid
> detection...), then a non-cryptographic checksum would be sufficient.
Wouldn't you also need a sign
On Thu, 2021-04-08 at 15:55 -0600, Jason A. Donenfeld wrote:
> On Thu, Apr 8, 2021 at 7:55 AM Simo Sorce wrote:
> > > I'm not sure this makes so much sense to do _in wireguard_. If you
> > > feel like the FIPS-allergic part is actually blake, 25519, chacha, and
> &
mately will do, but just throwing it here as a data
point.
Plus, as you note, it would overly complicate the interfaces.
As much as the check in wireguard is inelegant, it is much simpler to
understand and is not invasive.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
> of the problems. SP800-90B is the challenge. This is one of the motivation
> > of
> > the design and architecture of the LRNG allowing different types of crypto
> > and
> > have a different approach to post-process the data.
> >
> > https://github.com/smuellerDD/lrng
>
> Thanks Stephan for this info. After offline discussion with Herbert, here is
> what he said:
>
> """
> This is not a problem in RHEL8 because the Crypto API RNG replaces /dev/random
> in FIPS mode.
> """
>
> I'm not familiar with this code, not sure how upstream handle this.
It is an open problem upstream.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
On Fri, 2021-04-09 at 12:36 -0600, Jason A. Donenfeld wrote:
> On Fri, Apr 9, 2021 at 6:47 AM Simo Sorce wrote:
> > > depends on m || !CRYPTO_FIPS
> > >
> > > but I am a bit concerned that the rather intricate kconfig
> > > dependencies between the gener
On Fri, 2021-04-09 at 14:56 -0400, Simo Sorce wrote:
> Hi Jason,
> I can't speak for Hangbin, we do not work for the same company and I
> was not aware of his efforts until this patch landed.
Turns out I and Hangbin do work for the same company after all.
Left hand is meet
estore the entire system state from a
> > > swap file, and carry on as if the cold boot was just a [firmware
> > > assisted] suspend/resume.
> > >
> > > So forging collisions is *not* a concern here. Let's avoid accidental
> > > or malicious, as those adjectives seem to confuse some people. The
> > > bottom line is that there is no need to protect against deliberate
> > > attempts to hide the fact that the memory map has changed, and so
> > > there is no reason to use cryptographic hashes here.
> > >
> > How about :
> >
> > The check is intended to differentiate between a resume (which expects
> > an identical e820 map to the one saved in suspend), and a cold boot
> > (which need not have an identical e820 map to that saved in suspend if
> > any was done at all). It is not necessary here to protect against
> > deliberate attempts to hide the fact that the memory map has changed, so
> > crc32 is sufficient for detection.
> >
>
> Almost. Hibernation always occurs after a cold boot, but usually, the
> E820 memory map happens to be the same.
>
> How about
>
> """
> The check is intended to detect whether the E820 memory map provided
> by the firmware after cold boot unexpectedly differs from the one that
> was in use when the hibernation image was created. In this case, the
> hibernation image cannot be restored, as it may cover memory regions
> that are no longer available to the OS.
>
> A non-cryptographic hash such as CRC-32 is sufficient to detect such
> inadvertent deviations.
> """
hash -> checksum
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
14 matches
Mail list logo
