Mercurial > dropbear
view libtomcrypt/notes/tech0003.txt @ 1788:1fc0012b9c38
Fix handling of replies to global requests (#112)
The current code assumes that all global requests want / need a reply.
This isn't always true and the request itself indicates if it wants a
reply or not.
It causes a specific problem with [email protected] messages.
These are sent by OpenSSH after authentication to inform the client of
potential other host keys for the host. This can be used to add a new
type of host key or to rotate host keys.
The initial information message from the server is sent as a global
request, but with want_reply set to false. This means that the server
doesn't expect an answer to this message. Instead the client needs to
send a prove request as a reply if it wants to receive proof of
ownership for the host keys.
The bug doesn't cause any current problems with due to how OpenSSH
treats receiving the failure message. It instead treats it as a
keepalive message and further ignores it.
Arguably this is a protocol violation though of Dropbear and it is only
accidental that it doesn't cause a problem with OpenSSH.
The bug was found when adding host keys support to libssh, which is more
strict protocol wise and treats the unexpected failure message an error,
also see https://gitlab.com/libssh/libssh-mirror/-/merge_requests/145
for more information.
The fix here is to honor the want_reply flag in the global request and
to only send a reply if the other side expects a reply.
| author | Dirkjan Bussink <d.bussink@gmail.com> |
|---|---|
| date | Thu, 10 Dec 2020 16:13:13 +0100 |
| parents | 6dba84798cd5 |
| children |
line wrap: on
line source
Tech Note 0003 Minimizing Memory Usage Tom St Denis Introduction ------------ For the most part the library can get by with around 20KB of stack and about 32KB of heap even if you use the public key functions. If all you plan on using are the hashes and ciphers than only about 1KB of stack is required and no heap. To save space all of the symmetric key scheduled keys are stored in a union called "symmetric_key". This means the size of a symmetric_key is the size of the largest scheduled key. By removing the ciphers you don't use from the build you can minimize the size of this structure. For instance, by removing both Twofish and Blowfish the size reduces to 768 bytes from the 4,256 bytes it would have been (on a 32-bit platform). Or if you remove Blowfish and use Twofish with TWOFISH_SMALL defined its still 768 bytes. Even at its largest the structure is only 4KB which is normally not a problem for any platform. Cipher Name | Size of scheduled key (bytes) | ------------+-------------------------------| Twofish | 4,256 | Blowfish | 4,168 | 3DES | 768 | SAFER+ | 532 | Serpent | 528 | Rijndael | 516 | XTEA | 256 | RC2 | 256 | DES | 256 | SAFER [#] | 217 | RC5 | 204 | Twofish [*] | 193 | RC6 | 176 | CAST5 | 132 | Noekeon | 32 | Skipjack | 10 | ------------+-------------------------------/ Memory used per cipher on a 32-bit platform. [*] For Twofish with TWOFISH_SMALL defined [#] For all 64-bit SAFER ciphers. Noekeon is a fairly fast cipher and uses very little memory. Ideally in low-ram platforms all other ciphers should be left undefined and Noekeon should remain. While Noekeon is generally considered a secure block cipher (it is insecure as a hash) CAST5 is perhaps a "runner-up" choice. CAST5 has been around longer (it is also known as CAST-128) and is fairly fast as well. You can easily accomplish this via the "config.pl" script. Simply answer "n" to all of the ciphers except the one you want and then rebuild the library. [or you can hand edit tomcrypt_custom.h]