[Pkg-openssl-devel] Bug#747453: Arbitrary key size limitations causing hard-to-diagnose problems when establishing a connection

Benny Baumann BenBE at geshi.org
Sun May 11 12:13:39 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Florian,

Am 10.05.2014 22:42, schrieb Florian Weimer:
> * Benny Baumann:
>
>> As stated in the initial report you MUST never place arbitrary
>> limits on the size of cryptographic keys which is this bug is doing
>> in the first place.
>
> Actually, you have to, otherwise you end up with a rather trivial
> pre-authentication denial of service vulnerability.
But then you should decide this limit on more sophisticated and
situation based criteria than just "Oh, I think this key is too long",
which would make this much less arbitrary than saying "I don't like long
keys, thus I will barf out on them".

Example: Given a powerful high-security webserver versus an embedded
system you could just nicely argue that 4kBit RSA makes the login on
that 16MHz 8-bit microcontroller with barely 16KB RAM far too slow and
thus at most 2kBit keys should be accepted. On the other hand limiting
your webserver with some powerful highspeed 64bit multicore power-CPU
you'd be artificially limiting your security if you used only 2kBit
keys. In fact you would want to have a limit more at about 16kBit RSA or
alike to make full use of the security offered by your (yet artificial)
TLS1.3-ECDHE(p521r)-RSA-AES256-GCM-SHA512 cipher.

Or in short: The current hard-limit suites NEITHER the embedded system
NOR your powerful high-security webserver. Current patch for the RSA key
problem is a compromise in that it currently only increases the limit
from 516 Bytes (4k RSA) to 8200 Bytes (~64k RSA) to cure the imminent
symptoms we are facing which gives plenty of room for further
improvements (e.g. providing an API to set it or providing an API for a
callback so the application CAN decide if it wants).
> It's less of an
> issue for the plain RSA cipher suites, but for many of the more
> sophisticated ones, it is.
Any links for elaboration on that point? (Though I doubt they provide
ANY good reason for arbitrarily breaking crypto like this.)

Kind regards,
Benny Baumann.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCgAGBQJTb2lyAAoJEPHTXLno4S6tizkP/1wyiZhWEemHnrE1n5i4e8j2
XSrcTnhOKUlyIpaq3+EaLG8FK7mDyJWUv+2UiUctfungX+CuiyDXBc8CE0s9uUzO
QsEPKvHe5f7bPmMCgA4+LIJuPPf6Gmwi9LknYVznq5JTnFEQ86IrGaVeATcyoYKm
QWmZba/zx/0OFIpxbyTVPdOjR3zIdWNgm92JIBhme5JyUoy6UST/oUDBOHzKTIrl
fesoKm6NcvxgiOlDX2aAyZ0Vz69F7MwuBIUNnwH8cGJoj7F0nnJesMV+2dhtypT5
W0zxdhRUh2ZkM02+N4Typ9bnRryPaGHxO1jw2jIeuKK4zIRRTCC1lTrdEjDlzwNV
hYmGkJms2J3rJ7cefFhWusaGlyrwdX+HHAmTIvNHTtpVwr2ah6dVNeldzNSLjS+T
S756O6pL6JoocexrugjHlRM1y/LLu4wmCCJKwPILAygWqrmlFFo5V5ocLZqULoKA
Qhgb9hFHa0ZViFRjSPh+cT0YUnATgQzP6ZOWLISpRsxoV8La6/2B/lDxkjNVhQ7+
yMydmkcu+Aln4AemXIyH65vRef+BJeEGXamQP3SB9NcecyPh5dOhi56vvhWziU+h
H7x6fyEzKiiCQOdIGUbQQFqBcIN2egATl7XXxfMfu2Vw7Ayvs/MVNb54pLUuw4Lp
wE10pGNB4/Je8Haf5CrL
=vjOW
-----END PGP SIGNATURE-----



More information about the Pkg-openssl-devel mailing list