Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Dec 2008 11:28:17 +0300
From:      Eygene Ryabinkin <rea-fbsd@codelabs.ru>
To:        VANHULLEBUS Yvan <vanhu@FreeBSD.org>
Cc:        freebsd-net@freebsd.org, Christian Weisgerber <naddy@mips.inka.de>, gnn@freebsd.org
Subject:   Re: [ipsec] aes-ctr question
Message-ID:  <ASdPbGRGPS7DuYciPd76PqwseoE@zcEZVOCcHZY3I3dyQWw4Fw3cM6w>
In-Reply-To: <20081203082549.GA62889@zeninc.net>
References:  <49349E26.30002@redhat.com> <gh44rc$11fc$1@lorvorc.mips.inka.de> <JsLl5HMkEyWlPKM1sYjNK0G%2BM34@%2BFxG3S39oD8KW2mcneDQRW6aq9s> <20081203082549.GA62889@zeninc.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--YttKMwf6abDJOSyE
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Yvan, good day.

Wed, Dec 03, 2008 at 09:25:49AM +0100, VANHULLEBUS Yvan wrote:
> On Wed, Dec 03, 2008 at 10:54:55AM +0300, Eygene Ryabinkin wrote:
> [...]
> > Good catch.  Perhaps setkey should be extended to warn the user about
> > this neat.  The patch is attached.  George, people, what do you think
> > about it?
>=20
> If we're going to add security warnings in setkey, we could just put a
> warning when using static keys (so basically put a warning for "add"
> command....).

In general -- you're perfectly right: people should use IKE and company.

But CTR mode is particularily evil in respect to the nonce sinsitivity:
for the given key and initialization vector it will produce the same
gamma (running key in English terminology) used for encryption and
decryption.  But we seem to be more-or-less safe here: IV is generated
randomly, so one will have 2^64 different initialization vectors for a
single passphrase.

Sooo, the issue seems to be of a less value, but still -- it is here.
And for passive attacker who has access to all CTR mode sessions with
static keys will be rather simple to analyze for the gamma coincidence:
providing that the first bytes of the packets to be encrypted are the
same (think UDP/TCP header of something simular), then it should just
XOR the stream beginnings and wait when the bits that correspond to the
same (constant) bits of the payload will be zeroed.  Sufficient number
of zeros will indicate gamma coincidence and one can focus on further
fun with such streams.

Of course, I may be missing something.
--=20
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual  =20
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook=20
    {_.-``-'         {_/            #

--YttKMwf6abDJOSyE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)

iEYEARECAAYFAkk/faEACgkQthUKNsbL7YjQ5wCgtIylNp1663zN1UAqaSguoOj2
RJAAoKDTQmFOZ0SOi6mwpWCI8RAUEYh5
=agz9
-----END PGP SIGNATURE-----

--YttKMwf6abDJOSyE--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ASdPbGRGPS7DuYciPd76PqwseoE>