Discussion:
[PATCH][package] dropbear: enable sha2-based hmac by default.
(too old to reply)
Alive4Ever
2014-09-23 16:32:46 UTC
Permalink
Raw Message
Dropbear should support sha2-based message authentication.
This patch will enable hmac-sha2-256 and hmac-sha2-512.

------------------------
--- a/options.h
+++ b/options.h
@@ -128,8 +128,8 @@ much traffic. */
* which are not the standard form. */
#define DROPBEAR_SHA1_HMAC
/*#define DROPBEAR_SHA1_96_HMAC*/
-/*#define DROPBEAR_SHA2_256_HMAC*/
-/*#define DROPBEAR_SHA2_512_HMAC*/
+#define DROPBEAR_SHA2_256_HMAC
+#define DROPBEAR_SHA2_512_HMAC
#define DROPBEAR_MD5_HMAC

/* You can also disable integrity. Don't bother disabling this if you're
------------------------
Jo-Philipp Wich
2014-09-23 16:34:17 UTC
Permalink
Raw Message
Hi.
Post by Alive4Ever
Dropbear should support sha2-based message authentication.
This patch will enable hmac-sha2-256 and hmac-sha2-512.
Whats the size increase due to that?

~ Jow
Post by Alive4Ever
------------------------
--- a/options.h
+++ b/options.h
@@ -128,8 +128,8 @@ much traffic. */
* which are not the standard form. */
#define DROPBEAR_SHA1_HMAC
/*#define DROPBEAR_SHA1_96_HMAC*/
-/*#define DROPBEAR_SHA2_256_HMAC*/
-/*#define DROPBEAR_SHA2_512_HMAC*/
+#define DROPBEAR_SHA2_256_HMAC
+#define DROPBEAR_SHA2_512_HMAC
#define DROPBEAR_MD5_HMAC
/* You can also disable integrity. Don't bother disabling this if you're
------------------------
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Alive4Ever
2014-09-24 20:39:17 UTC
Permalink
Raw Message
Post by Jo-Philipp Wich
Whats the size increase due to that?
~ Jow
Here is a brief comparison about binary and package size
Tested on AR9330, mips, TL MR3220v2

Before applying sha2-hmac patch
***@OpenWrt:~# du -sh $(which dropbear)
161.5K /usr/sbin/dropbear

After applying sha2-hmac patch
***@OpenWrt:~# du -sh $(which dropbear)
165.5K /usr/sbin/dropbear

It's about 4K binary size increase.

debug information
ssh ***@OpenWrt -o MACs=hmac-sha2-512,hmac-sha2-256 -v
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha2-512 none
debug1: kex: client->server aes128-ctr hmac-sha2-512 none
...

Package size compared to downloaded trunk
84829 Sep 25 02:43 dropbear_2014.65-2_ar71xx.ipk
81896 Sep 25 02:13 dropbear_2014.65-2_ar71xx.ipk
It's about 3K package size increase.
Alive
2014-09-25 15:43:56 UTC
Permalink
Raw Message
X-Patchwork-Id: 6322
Message-Id: <BLU437-***@phx.gbl>

Is there any chance for my proposed patch to be committed?
http://patchwork.openwrt.org/patch/6322/

Here is a brief comparison about binary and package size increase.
Tested on AR9330, mips, TL MR3220v2

Before applying sha2-hmac patch
***@OpenWrt:~# du -sh $(which dropbear)
161.5K /usr/sbin/dropbear

After applying sha2-hmac patch
***@OpenWrt:~# du -sh $(which dropbear)
165.5K /usr/sbin/dropbear

It's about 4K binary size increase.

debug information
ssh ***@OpenWrt -o MACs=hmac-sha2-512,hmac-sha2-256 -v
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha2-512 none
debug1: kex: client->server aes128-ctr hmac-sha2-512 none
...

Package size compared to downloaded trunk
84829 Sep 25 02:43 dropbear_2014.65-2_ar71xx.ipk
81896 Sep 25 02:13 dropbear_2014.65-2_ar71xx.ipk
It's about 3K package size increase.
Catalin Patulea
2014-09-26 03:11:09 UTC
Permalink
Raw Message
What's the motivation for this change?
Post by Alive
X-Patchwork-Id: 6322
Is there any chance for my proposed patch to be committed?
http://patchwork.openwrt.org/patch/6322/
Here is a brief comparison about binary and package size increase.
Tested on AR9330, mips, TL MR3220v2
Before applying sha2-hmac patch
161.5K /usr/sbin/dropbear
After applying sha2-hmac patch
165.5K /usr/sbin/dropbear
It's about 4K binary size increase.
debug information
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha2-512 none
debug1: kex: client->server aes128-ctr hmac-sha2-512 none
...
Package size compared to downloaded trunk
84829 Sep 25 02:43 dropbear_2014.65-2_ar71xx.ipk
81896 Sep 25 02:13 dropbear_2014.65-2_ar71xx.ipk
It's about 3K package size increase.
_______________________________________________
openwrt-devel mailing list
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Alive
2014-09-26 18:15:30 UTC
Permalink
Raw Message
Post by Catalin Patulea
What's the motivation for this change?
Post by Alive
X-Patchwork-Id: 6322
Is there any chance for my proposed patch to be committed?
http://patchwork.openwrt.org/patch/6322/
Here is a brief comparison about binary and package size increase.
Tested on AR9330, mips, TL MR3220v2
Before applying sha2-hmac patch
161.5K /usr/sbin/dropbear
After applying sha2-hmac patch
165.5K /usr/sbin/dropbear
It's about 4K binary size increase.
debug information
...
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha2-512 none
debug1: kex: client->server aes128-ctr hmac-sha2-512 none
...
Package size compared to downloaded trunk
84829 Sep 25 02:43 dropbear_2014.65-2_ar71xx.ipk
81896 Sep 25 02:13 dropbear_2014.65-2_ar71xx.ipk
It's about 3K package size increase.
As SHA1 signature hash is about to be obsolete on certificates, it would
be better to prepare for next generation hash algorithms. Here are some
references.

http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
https://community.qualys.com/blogs/securitylabs/2014/09/09/sha1-deprecation-what-you-need-to-know
https://www.digicert.com/sha-2-ssl-certificates.htm

While CA is encouraging users to upgrade to SHA2-based certificates,
it'd be better to assume that SHA1 HMAC will also be obsolete.

I know unix philosophy "Don't fix what ain't broken".
I think it's better to provide safety measure to prevent disaster
instead of waiting the disaster to come and fix it later.
Weedy
2014-09-27 16:34:16 UTC
Permalink
Raw Message
I got bit by this last week when I audited my ssh config and dropped all
weak/slow ciphers.
Couldn't log into my routers and had to add md5 ciphers and macs back.
Alive
2014-09-27 17:29:07 UTC
Permalink
Raw Message
Post by Weedy
I got bit by this last week when I audited my ssh config and dropped all
weak/slow ciphers.
Couldn't log into my routers and had to add md5 ciphers and macs back.
You must rebuild dropbear package cleanly to test this patch

Save the patch as file located on
package/network/services/dropbear/patches/600-enable-hmac-sha2.patch,
relative to OpenWrt source directory. The patch is available here
http://patchwork.openwrt.org/patch/6322/

Do "make clean" to clean up the package, and then "make" to build the
firmware.
Flash the resulting firmware and test connecting to dropbear ssh daemon.

To test using hmac-sha2-256, run this command
ssh -o MACs=hmac-sha2-256 ***@OpenWrt
To test using hmac-sha2-512, run this command
ssh -o MACs=hmac-sha2-512 ***@OpenWrt

For your information, there is almost no difference between message
authentication algorithm in time needed to establish ssh connection.

I perform the test on my TL-MR3220 (AR9330, mips, dropbear 2014.65,
r42321). The identity file is cached via ssh-agent. The test commands
are bellow.
time ssh -o MACs=hmac-md5 OpenWrt /bin/true
time ssh -o MACs=hmac-sha1 OpenWrt /bin/true
time ssh -o MACs=hmac-sha2-256 OpenWrt /bin/true
time ssh -o MACs=hmac-sha2-512 OpenWrt /bin/true

Here are time needed to establish ssh connection
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m3.526s | 0m3.631s | 0m3.519s | 0m3.543s |
| user | 0m0.015s | 0m0.061s | 0m0.015s | 0m0.031s |
| sys | 0m0.077s | 0m0.046s | 0m0.093s | 0m0.092s |
+---------+----------+----------+----------+----------+

Putty and Bitvise will try connecting using hmac-sha2-256 when
available, whereas OpenSSH will use hmac-md5 by default.

I hope this information will be a good reason for enabling sha2-based
hmac on dropbear by default.
Weedy
2014-10-03 17:55:29 UTC
Permalink
Raw Message
Post by Alive
Post by Weedy
I got bit by this last week when I audited my ssh config and dropped all
weak/slow ciphers.
Couldn't log into my routers and had to add md5 ciphers and macs back.
You must rebuild dropbear package cleanly to test this patch
Save the patch as file located on
package/network/services/dropbear/patches/600-enable-hmac-sha2.patch,
relative to OpenWrt source directory. The patch is available here
http://patchwork.openwrt.org/patch/6322/
Do "make clean" to clean up the package, and then "make" to build the
firmware.
Flash the resulting firmware and test connecting to dropbear ssh daemon.
To test using hmac-sha2-256, run this command
To test using hmac-sha2-512, run this command
For your information, there is almost no difference between message
authentication algorithm in time needed to establish ssh connection.
I perform the test on my TL-MR3220 (AR9330, mips, dropbear 2014.65,
r42321). The identity file is cached via ssh-agent. The test commands
are bellow.
time ssh -o MACs=hmac-md5 OpenWrt /bin/true
time ssh -o MACs=hmac-sha1 OpenWrt /bin/true
time ssh -o MACs=hmac-sha2-256 OpenWrt /bin/true
time ssh -o MACs=hmac-sha2-512 OpenWrt /bin/true
Here are time needed to establish ssh connection
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m3.526s | 0m3.631s | 0m3.519s | 0m3.543s |
| user | 0m0.015s | 0m0.061s | 0m0.015s | 0m0.031s |
| sys | 0m0.077s | 0m0.046s | 0m0.093s | 0m0.092s |
+---------+----------+----------+----------+----------+
Putty and Bitvise will try connecting using hmac-sha2-256 when
available, whereas OpenSSH will use hmac-md5 by default.
I hope this information will be a good reason for enabling sha2-based
hmac on dropbear by default.
Based off failed ciphers/macs
no matching cipher found: client rijndael-***@lysator.liu.se server
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
no matching mac found: client hmac-ripemd160-***@openssh.com server
hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5

for cipher in 3des-cbc 3des-ctr aes128-cbc aes256-cbc aes128-ctr
aes256-ctr; do for mac in hmac-md5 hmac-sha1 hmac-sha2-256
hmac-sha2-512; do echo ""; echo "cipher: $cipher"; echo "mac: $mac"; for
bah in 1 2 3; do dd if=/dev/zero bs=1M count=25 | ssh -c "$cipher" -m
"$mac" -o "Compression no" ***@openwrt.lan 'time cat - >/dev/null';
echo ""; sleep 2; done; done; done

OpenSSH_6.6.1 connecting to TP-Link 4300, time to transfer 26MiB of junk
to null. Best of three, my router is in use and not idle.

3des-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m27.65s | 0m27.98s | 0m29.47s | 0m31.93s |
| user | 0m 0.05s | 0m 0.04s | 0m 0.02s | 0m 0.04s |
| sys | 0m 0.25s | 0m 0.22s | 0m 0.24s | 0m 0.22s |
+---------+----------+----------+----------+----------+

aes128-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m12.07s | 0m12.62s | 0m13.61s | 0m16.05s |
| user | 0m 0.02s | 0m 0.03s | 0m 0.00s | 0m 0.02s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.21s | 0m 0.22s |
+---------+----------+----------+----------+----------+

aes256-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m13.32s | 0m13.61s | 0m14.97s | 0m17.71s |
| user | 0m 0.02s | 0m 0.03s | 0m 0.03s | 0m 0.03s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.22s | 0m 0.28s |
+---------+----------+----------+----------+----------+

aes128-ctr
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m12.64s | 0m12.80s | 0m13.74s | 0m16.19s |
| user | 0m 0.04s | 0m 0.02s | 0m 0.02s | 0m 0.01s |
| sys | 0m 0.18s | 0m 0.24s | 0m 0.17s | 0m 0.23s |
+---------+----------+----------+----------+----------+

aes256-ctr
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m13.40s | 0m13.84s | 0m15.20s | 0m18.11s |
| user | 0m 0.01s | 0m 0.03s | 0m 0.02s | 0m 0.00s |
| sys | 0m 0.17s | 0m 0.16s | 0m 0.18s | 0m 0.24s |
+---------+----------+----------+----------+----------+


We should dump 3des-* and pick up arcfour*
Alive4Ever
2014-10-08 18:32:53 UTC
Permalink
Raw Message
Post by Weedy
Based off failed ciphers/macs
aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc
hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5
for cipher in 3des-cbc 3des-ctr aes128-cbc aes256-cbc aes128-ctr
aes256-ctr; do for mac in hmac-md5 hmac-sha1 hmac-sha2-256
hmac-sha2-512; do echo ""; echo "cipher: $cipher"; echo "mac: $mac"; for
bah in 1 2 3; do dd if=/dev/zero bs=1M count=25 | ssh -c "$cipher" -m
echo ""; sleep 2; done; done; done
OpenSSH_6.6.1 connecting to TP-Link 4300, time to transfer 26MiB of junk
to null. Best of three, my router is in use and not idle.
3des-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m27.65s | 0m27.98s | 0m29.47s | 0m31.93s |
| user | 0m 0.05s | 0m 0.04s | 0m 0.02s | 0m 0.04s |
| sys | 0m 0.25s | 0m 0.22s | 0m 0.24s | 0m 0.22s |
+---------+----------+----------+----------+----------+
aes128-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m12.07s | 0m12.62s | 0m13.61s | 0m16.05s |
| user | 0m 0.02s | 0m 0.03s | 0m 0.00s | 0m 0.02s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.21s | 0m 0.22s |
+---------+----------+----------+----------+----------+
aes256-cbc
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m13.32s | 0m13.61s | 0m14.97s | 0m17.71s |
| user | 0m 0.02s | 0m 0.03s | 0m 0.03s | 0m 0.03s |
| sys | 0m 0.27s | 0m 0.23s | 0m 0.22s | 0m 0.28s |
+---------+----------+----------+----------+----------+
aes128-ctr
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m12.64s | 0m12.80s | 0m13.74s | 0m16.19s |
| user | 0m 0.04s | 0m 0.02s | 0m 0.02s | 0m 0.01s |
| sys | 0m 0.18s | 0m 0.24s | 0m 0.17s | 0m 0.23s |
+---------+----------+----------+----------+----------+
aes256-ctr
+---------+----------+----------+----------+----------+
|time\hmac| md5 | sha1 | sha256 | sha512 |
+---------+----------+----------+----------+----------+
| real | 0m13.40s | 0m13.84s | 0m15.20s | 0m18.11s |
| user | 0m 0.01s | 0m 0.03s | 0m 0.02s | 0m 0.00s |
| sys | 0m 0.17s | 0m 0.16s | 0m 0.18s | 0m 0.24s |
+---------+----------+----------+----------+----------+
We should dump 3des-* and pick up arcfour*
Thanks for performing cipher speed test in addition with hmac test.
I realize that there is no need to enable stronger hash function for
hmac. The md5 collision attacks and 'predicted' sha1 collision attacks
are just affecting `pure` digest function. There is no known attack
affecting hmac-md5 or hmac-sha1, because hmac is not as simple as
digest. It's an advanced operation to verify deciphered message,
operating blocks by blocks repeatedly. It's sure hard to perform
collision attack on hmac, because the underlying layer is already
encrypted, for example by aes128-ctr cipher.

Currently, there is no formal advice to enable stronger digest for hmac.
The well known OpenSSH is still using hmac-md5 as default message
authentication algorithm, although it has added support for sha2-based
hmac since 5.9. To be specified, OpenSSH is using
hmac-md5-***@openssh.com - a special extension added by OpenSSH to add
more security to hmac-md5 - if the server supports it.

IETF says that hmac-md5 isn't broken, although the md5 hash function is
considered weak to collision attacks.

https://www.ietf.org/mail-archive/web/cfrg/current/msg01202.html

There is no need to rush. I know that when the time comes, OpenWrt
developers will enable hmac-sha2 by default. Maybe years from now, or
when the dropbear upstream enables hmac-sha2 by default.

Loading...