Conversation
|
libsodium does not provide AES128GCM + SHA256 or AES256GCM + SHA384, which means that it is impossible to use libsodium-only to support TLS 1.3 using AES. |
|
This PR is parked - a minicrypto-binding with support for P256 and AES128-GCM has been merged in #16. |
|
@kazuho libsodium support SHA256 and aes256gcm now, can we use it with picotls ? |
ASAN finding:
```
=================================================================
==24799==ERROR: AddressSanitizer: global-buffer-overflow on address 0x55841ae13761 at pc 0x55841aced3ec bp 0x7ffca51cae30 sp 0x7ffca51ca5e0
READ of size 48 at 0x55841ae13761 thread T0
#0 0x55841aced3eb in __asan_memcpy (/home/def/p/floss/picotls/test-openssl.t+0x1603eb)
h2o#1 0x55841ad882db in ptls_hmac_create /home/def/p/floss/picotls/t/../lib/picotls.c:4680:5
h2o#2 0x55841ad899e3 in ptls_hkdf_expand /home/def/p/floss/picotls/t/../lib/picotls.c:4709:25
h2o#3 0x55841ad87dcd in hkdf_expand_label /home/def/p/floss/picotls/t/../lib/picotls.c:4751:11
h2o#4 0x55841ad8a500 in ptls_hkdf_expand_label /home/def/p/floss/picotls/t/../lib/picotls.c:4764:12
h2o#5 0x55841ad8a500 in get_traffic_key /home/def/p/floss/picotls/t/../lib/picotls.c:1090
h2o#6 0x55841ad8a500 in new_aead /home/def/p/floss/picotls/t/../lib/picotls.c:4798
h2o#7 0x55841add8597 in ptls_aead_new /home/def/p/floss/picotls/t/../lib/picotls.c:4818:12
h2o#8 0x55841add8597 in test_ciphersuite /home/def/p/floss/picotls/t/picotls.c:122
h2o#9 0x55841ad9a4ed in test_aes256gcm /home/def/p/floss/picotls/t/picotls.c:241:9
h2o#10 0x55841ad69d3f in subtest /home/def/p/floss/picotls/deps/picotest/picotest.c:96:5
h2o#11 0x55841ad99615 in test_picotls /home/def/p/floss/picotls/t/picotls.c:1161:5
h2o#12 0x55841ad69d3f in subtest /home/def/p/floss/picotls/deps/picotest/picotest.c:96:5
h2o#13 0x55841ade8e5b in main /home/def/p/floss/picotls/t/openssl.c:277:5
h2o#14 0x7faf59057222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
h2o#15 0x55841ac1b7cd in _start (/home/def/p/floss/picotls/test-openssl.t+0x8e7cd)
0x55841ae13761 is located 63 bytes to the left of global variable '<string literal>' defined in '/home/def/p/floss/picotls/t/picotls.c:116:78' (0x55841ae137a0) of size 12
'<string literal>' is ascii string 'hello world'
0x55841ae13761 is located 0 bytes to the right of global variable '<string literal>' defined in '/home/def/p/floss/picotls/t/picotls.c:116:34' (0x55841ae13740) of size 33
'<string literal>' is ascii string '01234567890123456789012345678901'
SUMMARY: AddressSanitizer: global-buffer-overflow (/home/def/p/floss/picotls/test-openssl.t+0x1603eb) in __asan_memcpy
Shadow bytes around the buggy address:
0x0ab1035ba690: f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9 00 00 05 f9
```
|
@patrickkh7788 TLS 1.3 requires AES128-GCM and P-256. But if there is enough interest, I can make a standalone library that only implements what's required for TLS 1.3. |
|
@jedisct1 Thank you for suggesting that. My preference was to use libsodium, however due to lack of support for the AES128-GCM and P-256, we introduced the "minicrypto" backend that uses micro-ecc and cifra, so that picotls can be built and used without using OpenSSL. That's working fine, and honestly speaking I do not want to have another backend, because it just increases the maintenance cost (especially when the internal API between picotls core and the crypto bindings change). |
|
Is there maybe a performance argument for libsodium over openssl? minicrypto is clearly completely useless from a performance standpoint. |
|
Performance-wise, I think adding a backend for https://github.com/intel/ipp-crypto could be a good idea. |
4 participants
[ ] AESGCM