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
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
> 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
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
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
> &
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
On Fri, 2018-02-02 at 18:24 -0500, Paul Moore wrote:
> On Fri, Feb 2, 2018 at 5:19 PM, Simo Sorce wrote:
> > On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> > > On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs
> > > wrote:
> > > > On 2018-01-0
On Fri, 2018-02-02 at 16:24 -0500, Paul Moore wrote:
> On Wed, Jan 10, 2018 at 2:00 AM, Richard Guy Briggs wrote:
> > On 2018-01-09 11:18, Simo Sorce wrote:
> > > On Tue, 2018-01-09 at 07:16 -0500, Richard Guy Briggs wrote:
> > > > Containers are a userspace concept
stem or you want to
correlate the system audit logs with other components dealing with
containers, now you need a place where you provide a mapping from your
audit u64 to the ID a container has in the rest of the system.
b) Now you need a mapping of some sort. The simplest way a container
orchestrator can go about this is to just use the UUID or Hash
representing their view of the container, truncate it to a u64 and use
that for Audit. This means there are some chances there will be a
collision and a duplicate u64 ID will be used by the orchestrator as
the container ID. What happen in that case ?
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
On Tue, 2017-10-17 at 07:59 -0700, Casey Schaufler wrote:
> On 10/17/2017 5:31 AM, Simo Sorce wrote:
> > On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote:
> > > On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs
> > > wrote:
> > > > There is su
ontainer ID means the process has
> the ability to indirectly control the audit trail.
The container Id can be used also for authorization purposes (by other
processes on the host), not just audit, I think this is why a separate
control has been proposed.
Simo.
--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
11 matches
Mail list logo
