On Sat, Feb 28, 2015 at 01:08:03PM +0100, Stephan Mueller wrote:
> Am Samstag, 28. Februar 2015, 23:47:12 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Thu, Feb 19, 2015 at 07:56:48AM +0100, Stephan Mueller wrote:
> > > In case of rfc4106(gcm(aes)), the IV is 96 bits. Thus, our constructed
> >
>
Am Samstag, 28. Februar 2015, 23:47:12 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Feb 19, 2015 at 07:56:48AM +0100, Stephan Mueller wrote:
> > In case of rfc4106(gcm(aes)), the IV is 96 bits. Thus, our constructed
>
> > IV looks like:
> The IV to rfc4106 is 96 bits, but the IV to the underlying g
On Thu, Feb 19, 2015 at 07:56:48AM +0100, Stephan Mueller wrote:
>
> In case of rfc4106(gcm(aes)), the IV is 96 bits. Thus, our constructed
> IV looks like:
The IV to rfc4106 is 96 bits, but the IV to the underlying gcm
is 128 bits so that's what guarantees the uniqueness.
Cheers,
--
Email: Her
Hi,
I had some offline discussion with Stephan and it seems to me
at least that it is very hard to use the described "Deterministic"
method under Linux while at the same time still keeping the
uniqueness requirement to stay FIPS 140-2 certifiable.
How about going full randomized IV generation on
Hi Herbert,
After some research, we think that the current implementation of seqiv
as used for GCM does not comply with SP800-38D. Before I outline the
issue, please allow me to state my understanding of seqiv (to make sure
I really understand it :-) ).
Seqiv works as a wrapper around the asso
