More with AES GCM/GMAC

[Chris Rogers]

--e89a8ff243c1a17c3704c531a204
Content-Type: text/plain; charset=ISO-8859-1

This is in reference to Alex's reply
here<http://leaf.dragonflybsd.org/mailarchive/kernel/2012-07/msg00023.html>
.

So, let's use this scenario.  I'm using an IPsec client that chooses AES
GCM 16 as its mode of encryption for ESP.  It creates a security
association (SA) object, and sends that to the kernel via a socket.  It is
worthy to note that the authentication portion of this SA is null because
it is assumed that GCM will inherently ensure integrity.  When this SA
reaches the kernel, and is processed through xform_esp.c, key.c, and when
it finally reaches cryptosoft.c, there's only one session in the swcr_data
struct; namely, the one for GCM.  When we try to step through the switch
statement, we correctly set the following since it sw->sw_alg is recognized
as the CRYPTO_AES_GCM_16 case :

swe = sw;
crde = crd;
exf = swe->sw_exf;
ivlen = exf->blocksize;

However, since there are no more sessions to jump into any of the
CRYPTO_AES_*_GMAC cases, we fail to set any of these:

swa = sw;
crda = crd;
axf = swa->sw_axf;
if (swa->sw_ictx == 0)
    return (EINVAL);
bcopy(swa->sw_ictx, &ctx, axf->ctxsize);
blksz = axf->blocksize;

which are needed by the subsequent if statement:

if (crde == NULL || crda == NULL)
        return (EINVAL);

Thus, we return from swcr_combined with an error value of 22 for Invalid
Arguments.

I'm assuming that the native IPsec client on Dragonfly somehow accounts for
this, and will correctly initialize a second session to ensure that the
GMAC portion is executed. Pfkeyv2.h doesn't have a SADB_X_AALG ID defined
for GMAC, so it must only be used for encryption, and yet the GMACs are
defined in auth_hash structs.  So, my next question is, how is that session
created?  How do we get the GMAC case to trigger, and lend its portion of
the encryption to GCM without specifying it explicitly as an authentication
algorithm in the SA (because that creates a whole host of other problems a
lot deeper in the kernel)?

--e89a8ff243c1a17c3704c531a204
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is in reference to Alex's reply <a href=3D"http://leaf.dragonflybs=
d.org/mailarchive/kernel/2012-07/msg00023.html">here</a>.<br><br>So, let&#3=
9;s use this scenario.=A0 I'm using an IPsec client that chooses AES GC=
M 16 as its mode of encryption for ESP.=A0 It creates a security associatio=
n (SA) object, and sends that to the kernel via a socket.=A0 It is worthy t=
o note that the authentication portion of this SA is null because it is ass=
umed that GCM will inherently ensure integrity.=A0 When this SA reaches the=
 kernel, and is processed through xform_esp.c, key.c, and when it finally r=
eaches cryptosoft.c, there's only one session in the swcr_data struct; =
namely, the one for GCM.=A0 When we try to step through the switch statemen=
t, we correctly set the following since it sw->sw_alg is recognized as t=
he CRYPTO_AES_GCM_16 case :<br>
<br>swe =3D sw;<br>crde =3D crd;<br>exf =3D swe->sw_exf;<br>ivlen =3D ex=
f->blocksize;<br><br>However, since there are no more sessions to jump i=
nto any of the CRYPTO_AES_*_GMAC cases, we fail to set any of these: <br><b=
r>swa =3D sw;<br>
crda =3D crd;<br>axf =3D swa->sw_axf;<br>if (swa->sw_ictx =3D=3D 0)<b=
r>=A0=A0=A0 return (EINVAL);<br>bcopy(swa->sw_ictx, &ctx, axf->ct=
xsize);<br>blksz =3D axf->blocksize;<br><br>which are needed by the subs=
equent if statement:<br>
<br>if (crde =3D=3D NULL || crda =3D=3D NULL)<br>=A0=A0=A0 =A0=A0=A0 return=
 (EINVAL);<br><br>Thus, we return from swcr_combined with an error value of=
 22 for Invalid Arguments.=A0 <br><br>I'm assuming that the native IPse=
c client on Dragonfly somehow accounts for this, and will correctly initial=
ize a second session to ensure that the GMAC portion is executed. Pfkeyv2.h=
 doesn't have a SADB_X_AALG ID defined for GMAC, so it must only be use=
d for encryption, and yet the GMACs are defined in auth_hash structs.=A0 So=
, my next question is, how is that session created?=A0 How do we get the GM=
AC case to trigger, and lend its portion of the encryption to GCM without s=
pecifying it explicitly as an authentication algorithm in the SA (because t=
hat creates a whole host of other problems a lot deeper in the kernel)? <br=
>

--e89a8ff243c1a17c3704c531a204--