DTLS #1
Comments
|
Hello. Is DTLS now planned in the roadmap? I think this is a must have. |
|
We're actively working on it! |
|
Thank you for your answer. Do you have a rough idea of the release date? Regards, On Tue, Jul 1, 2014 at 11:01 AM, Manuel Pégourié-Gonnard <
|
|
Paul has more experience than me with the release cycle, so if he disagrees please trust him rather than me, but my own personal impression is that we could have a preview branch available in the next few months and aim for an actual release before the end of 2014. |
|
Hello, I'm coming back to you about the DTLS. Sorry for bothering you. Do you have Thank you in advance. On Tue, Jul 1, 2014 at 11:01 AM, Manuel Pégourié-Gonnard <
|
|
Hello Stephane, We are in the process of making the first public release of a new branch with DTLS. Development has finished and testing is in progress as we speak. If you send me an e-mail, we can provide you an unofficial pre-release already. |
|
That's very good thank you. I can wait for the public release. Thanks for the hard work. On Thu, Oct 23, 2014 at 11:02 AM, Paul Bakker notifications@github.com
|
|
In fact, I'd like to have a look at the preliminary DTLS version. Is that possible? Regards, On Thu, Oct 23, 2014 at 2:45 PM, Stephane DI VITO <stephane.divito@gmail.com
|
|
Please send us a contact e-mail and I'll send it to you. |
|
I'll just bump this. I'm investigating what library to use for an embedded commercial system that will use DTLS, and can't find any information with regards to DTLS support officially from PolarSSL. How's it coming..? :) |
|
+1 :) |
|
https://polarssl.org/tech-updates/releases/mbedtls-1.4-dtls-preview-released Let us emphasize that this is a preview, not a new stable branch. |
|
Oops, s/polarssl/mbedtls/ :) I just fixed the post. The download page already had the correct link: https://polarssl.org/download-archive |
IAR compiler errors handling
Tests: add omitted dependency on MBEDTLS_ECDSA_C in test_suite_debug
The previous code used comparison operators >= and == that are quite likely to
be compiled to branches by some compilers on some architectures (with some
optimisation levels).
For example, take the following function:
void old_update( size_t data_len, size_t *padlen )
{
*padlen *= ( data_len >= *padlen + 1 );
}
With Clang 3.8, let's compile it for the Arm v6-M architecture:
% clang --target=arm-none-eabi -march=armv6-m -Os foo.c -S -o - |
sed -n '/^old_update:$/,/\.size/p'
old_update:
.fnstart
@ BB#0:
.save {r4, lr}
push {r4, lr}
ldr r2, [r1]
adds r4, r2, #1
movs r3, #0
cmp r4, r0
bls .LBB0_2
@ BB#1:
mov r2, r3
.LBB0_2:
str r2, [r1]
pop {r4, pc}
.Lfunc_end0:
.size old_update, .Lfunc_end0-old_update
We can see an unbalanced secret-dependant branch, resulting in a total
execution time depends on the value of the secret (here padlen) in a
straightforward way.
The new version, based on bit operations, doesn't have this issue:
new_update:
.fnstart
@ BB#0:
ldr r2, [r1]
subs r0, r0, #1
subs r0, r0, r2
asrs r0, r0, #31
bics r2, r0
str r2, [r1]
bx lr
.Lfunc_end1:
.size new_update, .Lfunc_end1-new_update
(As a bonus, it's smaller and uses less stack.)
While there's no formal guarantee that the version based on bit operations in
C won't be translated using branches by the compiler, experiments tend to show
that's the case [1], and it is commonly accepted knowledge in the practical
crypto community that if we want to sick to C, bit operations are the safest
bet [2].
[1] https://github.com/mpg/ct/blob/master/results
[2] https://github.com/veorq/cryptocoding
Signed-off-by: Manuel Pégourié-Gonnard <manuel.pegourie-gonnard@arm.com>
Summary: We try to [mbedtls_free](https://github.com/hannestschofenig/mbedtls/blob/tls13-prototype/library/ssl_tls.c#L6439-L6440) object inside `handshake` after its address is zeroed out by [mbedtls_platform_zeroize](https://github.com/hannestschofenig/mbedtls/blob/tls13-prototype/library/ssl_tls.c#L6426) Test Plan: Here is from our report. ``` ================================================================= ==3365627==ERROR: LeakSanitizer: detected memory leaks Direct leak of 256 byte(s) in 1 object(s) allocated from: #0 0x1ab37c7 in calloc (/data/users/lhuang04/fbsource/fbcode/buck-out/dbg/cells/fbsource/gen/aab7ed39/xplat/mobilenetwork/test/test+0x1ab37c7) Mbed-TLS#1 0x10f549d in ssl_server_hello_postprocess xplat/mobilenetwork/third-party/mbedtls/library/ssl_tls13_client.c:3369 Mbed-TLS#2 0x10e7e2e in ssl_server_hello_process xplat/mobilenetwork/third-party/mbedtls/library/ssl_tls13_client.c:2864 Mbed-TLS#3 0x10e6b6c in mbedtls_ssl_handshake_client_step_tls1_3 xplat/mobilenetwork/third-party/mbedtls/library/ssl_tls13_client.c:4175 Mbed-TLS#4 0x10dfd77 in mbedtls_ssl_handshake_step xplat/mobilenetwork/third-party/mbedtls/library/ssl_tls.c:6090 ``` Reviewers: Subscribers: Tasks: Tags:
The PSA Crypto API uses 0 as the initial counter value, but the test vector
in RFC 7539 uses 1. So the unit tests here include an extra leading block.
The expected data for this leading block was calculated with Cryptodome.
#!/usr/bin/env python3
import re
from Cryptodome.Cipher import ChaCha20
key = bytes.fromhex('000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f')
nonce = bytes.fromhex('000000000000004a00000000')
encrypt = lambda pt: ChaCha20.new(key=key, nonce=nonce).encrypt(pt)
# Cryptodome uses counter=0, like PSA Crypto. Prepend a 64-byte input block #0
# so that the plaintext from RFC 7539 starts exactly at block #1.
header = b'The RFC 7539 test vector uses counter=1, but PSA uses counter=0.'
assert(len(header) == 64)
sunscreen = b"Ladies and Gentlemen of the class of '99: If I could offer you only one tip for the future, sunscreen would be it."
plaintext = header + sunscreen
zeros = b'\x00' * len(plaintext)
keystream = encrypt(zeros)
ciphertext = encrypt(plaintext)
print('RFC 7539 §2.4.2')
print('Keystream:')
print(re.sub(r'(..)', r'\1:', keystream[64:].hex()))
print('Ciphertext Subscreen:')
print(re.sub(r'(..)', r'\1 ', ciphertext[64:].hex()))
print('')
print(f"""\
PSA symmetric decrypt: ChaCha20, RFC7539 keystream
depends_on:PSA_WANT_ALG_STREAM_CIPHER:PSA_WANT_KEY_TYPE_CHACHA20
# Keystream from RFC 7539 §2.4.2, with an extra 64-byte output block prepended
# because the test vector starts at counter=1 but our API starts at counter=0.
cipher_decrypt:PSA_ALG_STREAM_CIPHER:PSA_KEY_TYPE_CHACHA20:"{key.hex()}":"{nonce.hex()}":"{zeros.hex()}":"{keystream.hex()}"
PSA symmetric decrypt: ChaCha20, RFC7539 sunscreen
depends_on:PSA_WANT_ALG_STREAM_CIPHER:PSA_WANT_KEY_TYPE_CHACHA20
# Test vector from RFC 7539 §2.4.2, with an extra 64-byte block prepended
# because the test vector starts at counter=1 but our API starts at counter=0.
cipher_decrypt:PSA_ALG_STREAM_CIPHER:PSA_KEY_TYPE_CHACHA20:"{key.hex()}":"{nonce.hex()}":"{ciphertext.hex()}":"{plaintext.hex()}"
""")
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
…e causing issues
This commit needs to be dropped when real reason is found for:
Sign alg from PK: RSA_PSS(SHA256), not supported .................. ==587199==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x4cd774 in mbedtls_debug_print_msg (/home/przemek/mbedtls/tests/test_suite_ssl+0x4cd774)
Mbed-TLS#1 0x536e76 in mbedtls_ssl_tls13_get_sig_alg_from_pk (/home/przemek/mbedtls/tests/test_suite_ssl+0x536e76)
Mbed-TLS#2 0x4beeb7 in test_get_sig_alg_from_pk (/home/przemek/mbedtls/tests/test_suite_ssl+0x4beeb7)
Mbed-TLS#3 0x4bf2dc in test_get_sig_alg_from_pk_wrapper (/home/przemek/mbedtls/tests/test_suite_ssl+0x4bf2dc)
Mbed-TLS#4 0x4c199f in execute_tests (/home/przemek/mbedtls/tests/test_suite_ssl+0x4c199f)
Mbed-TLS#5 0x4c2e86 in main (/home/przemek/mbedtls/tests/test_suite_ssl+0x4c2e86)
Mbed-TLS#6 0x7f4a5c8c60b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
Mbed-TLS#7 0x41c37d in _start (/home/przemek/mbedtls/tests/test_suite_ssl+0x41c37d)
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
…e causing issues
This commit needs to be dropped when real reason is found for:
Sign alg from PK: RSA_PSS(SHA256), not supported .................. ==587199==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x4cd774 in mbedtls_debug_print_msg (/home/przemek/mbedtls/tests/test_suite_ssl+0x4cd774)
Mbed-TLS#1 0x536e76 in mbedtls_ssl_tls13_get_sig_alg_from_pk (/home/przemek/mbedtls/tests/test_suite_ssl+0x536e76)
Mbed-TLS#2 0x4beeb7 in test_get_sig_alg_from_pk (/home/przemek/mbedtls/tests/test_suite_ssl+0x4beeb7)
Mbed-TLS#3 0x4bf2dc in test_get_sig_alg_from_pk_wrapper (/home/przemek/mbedtls/tests/test_suite_ssl+0x4bf2dc)
Mbed-TLS#4 0x4c199f in execute_tests (/home/przemek/mbedtls/tests/test_suite_ssl+0x4c199f)
Mbed-TLS#5 0x4c2e86 in main (/home/przemek/mbedtls/tests/test_suite_ssl+0x4c2e86)
Mbed-TLS#6 0x7f4a5c8c60b2 in __libc_start_main /build/glibc-sMfBJT/glibc-2.31/csu/../csu/libc-start.c:308:16
Mbed-TLS#7 0x41c37d in _start (/home/przemek/mbedtls/tests/test_suite_ssl+0x41c37d)
Signed-off-by: Przemek Stekiel <przemyslaw.stekiel@mobica.com>
Test PR for Github merge queues #1
pull the latest commits from the origin.
…or SHA256 digest in extended RSA testcase Merge in MCUCORE/mcu-sdk-mbedtls from bugfix/MCUX-56607-build-warnings-in-middleware-mbedtls-library-rsa.c to master * commit '4dc8ba304ac6aeb54bc42626aaa291bad6e8576b': [MCUX-56607][MbedTLS][ELE] Resolve warning for SHA256 digest in extended RSA testcase
Request for DTLS support as this would increase usability for my projects.
The text was updated successfully, but these errors were encountered: