- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Gilles Peskine

Hello, On 05/11/2020 17:49, François Beerten via mbed-tls wrote: > Hi, > > Thank you Gilles for the detailed reply. > > Do you prefer that discussion about PSA Crypto API spec go on mailing > list instead of here ? Is there some room for evolution or is the spec > already in a frozen released state ? Please use the psa-crypto list since there may be participants there who don't care about Mbed TLS. Version 1.0 of the PSA Crypto API is official so we won't make incompatible changes unless there is a compelling reason. We can, and will, add features in 1.x versions of the specification. Among planned features are: more algorithm declarations, key wrapping, key stretching, and a better treatment of key establishment (including password-based key establishment). > > For new algorithms, it's of course preferable that they're defined in > the spec itself. But does the mbedtls project want to supports all > algorithms that will be used with PSA Crypto API ? Mbed TLS intends to be a reference implementation of the PSA crypto API. However it isn't clear whether this means that Mbed TLS will eventually support all algorithms that the API declares: we intend to support all methods, but not necessarily all algorithms. A conforming implementation of the API is allowed to support any subset of the algorithms. We (here meaning Arm, not Mbed TLS) don't have a formal policy to decide whether to include a declaration for an algorithm, but here are some criteria that we're likely to follow: * There should be a public specification. (This can be a document that's only for purchase, such as an ISO standard.) * The algorithm should either be in good standing, or in current use in legacy protocols. * The bar is low for adding an algorithm that just requires a #define. It's a lot higher if a new function is needed. * Availability in Mbed TLS is not required. > > For pure ED25519 and ED448 with scattered data, there's one big > gotcha. You need to generate twice a hash that includes the message. > Thus the implementation needs to be able to access the buffers of the > message twice. With a piece of the message given only once as in the > init-update-finish scheme, that does not work well. > > From reading the document on the PSA Crypto driver API, a transparent > driver benefits from the management of keys done by the mbedtls > implementation. But what benefit is there for a driver working with > opaque keys which has to fully handle the protections and restrictions > of keys internally ? > One of the driving goals of PSA is to make security unobtrusive, and to facilitate security improvements. A unified interface to key management makes it easy to upgrade from having all keys inside, to using a single-chip application separation technology (MMU, MPU, secure enclave, …), to wrapping keys in a secure element and storing the wrapped key externally, to storing keys in a secure element (which protects against undeletion). When an application uses a key, it doesn't need to care where the key is stored. Best regards, -- Gilles Peskine > Best, > > François. > > > On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Thank you for your interest in the PSA crypto API. >> >> On 28/10/2020 15:20, François Beerten via mbed-tls wrote: >>> Hi everybody, >>> >>> After reading the PSA Crypto API specs (as on >>> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) >>> and looking at the mbed TLS library, a few questions came up. >>> >>> Is there some repository with the sources of the PSA Crypto API specs >>> where one can follow the evolution and eventually send proposals and >>> patches ? >>> >> The PSA specification drafts are not public. You can send feedback about >> the PSA Crypto application and driver interfaces on the psa-crypto >> mailing list (psa-crypto(a)lists.trustedfirmware.org, >> https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you >> prefer to send confidential feedback, you can email mbed-crypto(a)arm.com >> (feedback at this address will only be discussed inside Arm). An issue >> in the Mbed TLS repository will also reach PSA Crypto architects. >> >>> A note says "Hash suspend and resume is not defined for the SHA3 >>> family of hash algorithms". Why are they not defined for SHA3 ? >>> >> The hash suspend/resume operations marshall the internal state of the >> hash operation. They mimic an existing JavaCard API >> (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). >> >> There is a de facto standard representation of the internal state for >> common Merkle-Damgård constructions, which covers all the currently >> defined hash algorithms except SHA3. If there's interest in this >> functionality, we could standardize a representation for SHA3. >> >>> How can or should one add support in PSA Crypto AP for not yet defined >>> algorithms (for example a KDF) ? >>> >> Answer from a PSA Crypto architect: preferably by requesting an encoding >> for this KDF as a PSA_ALG_xxx value (as well as new >> PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do >> that, use an encoding in the vendor range (most significant bit set). >> >> The world of key derivation functions is unfortunately messy: there are >> many similar, but not functionally equivalent constructions (such as >> hashing a secret together with a nonce, formatted in all kinds of >> different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set >> required for the TLS protocol. We expect 1.0.x updates to define more >> KDF algorithms. >> >> Answer from an Mbed TLS maintainer: contributing an implementation would >> be appreciated (but not required). >> >>> In multipart operations, can the user reuse the input buffers >>> immediately after doing an 'update' (for example after >>> psa_hash_update()) ? And can he reuse the input buffers immediately >>> after some "setup" functions like psa_cipher_set_iv() or >>> psa_aead_set_nonce() ? >>> >> Yes. PSA crypto API functions that take a buffer as a parameter never >> take ownership of that buffer. Once the function returns, you can do >> whatever you want with the buffer. >> >> The PSA specification even guarantees that you can use the same buffer, >> or overlapping buffers, as inputs and outputs to the same function call. >> However beware that the Mbed TLS implementation does not always support >> such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). >> >>> Do you plan to support (pure) ED25519 and ED448 only via >>> psa_sign_message() and psa_verify_message() ? What about messages in >>> multiple chunks ? >>> >> We plan to add a multi-part message signature interface, both for the >> sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I >> expect the design to be “what you'd expect” but I haven't yet verified >> that there aren't any gotchas. >> >>> In psa_asymmetric_encrypt(), why is the salt provided explicitely. >>> Shouldn't it be generated randomly internally when needed ? >>> >> Some applications use a fixed or deterministic salt which they check on >> decryption. Note that this parameter is what PKCS#1 calls “label”. >> >>> With PSA Crypto API, you define a flexible API for cryptographic >>> operations. Apparently, other providers could make their own >>> implementation of PSA Crypto API. Will mbed TLS then be able to use >>> those alternate PSA Crypto API implementations ? How would that work >>> practically ? >>> >> The X.509 and TLS layer of Mbed TLS are currently designed to use the >> mbedtls_xxx crypto API. We have already added partial support for the >> psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet >> possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto >> implementation. (I think this is already possible for a small set of >> cipher suites, but it isn't something that we've tried or currently >> actively support.) Before this can happen, some Mbed TLS APIs need to >> change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan >> to decouple the PSA crypto reference implementation (Mbed TLS's current >> crypto implementation) from the X.509/TLS layer (which will remain “Mbed >> TLS”). Our plans >> (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far >> into the future are still vague and may change. >> >> Note that for the most common case of wanting a different implementation >> of cryptography, which is to leverage hardware such as accelerators and >> secure elements, PSA is defining a driver interface which is currently >> being implemented in Mbed TLS >> (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). >> >> The driver interface lets you combine mechanisms supported by your >> hardware with Mbed TLS's implementation for mechanisms without hardware >> support. >>

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi Francois, The workshop slides and recordings are now available here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Regards, Shebu From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of François Beerten via mbed-tls Sent: Thursday, November 5, 2020 4:52 PM To: mbed-tls(a)lists.trustedfirmware.org Subject: Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow Hi Shebu, Will you post the slides of the presentations of the workshop ? Thanks, François. On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote: Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com><mailto:linaro.org_havjv2figrh5egaiurb229pd8c@group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org>; Don Harbin; psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org>; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Mbed TLS Virtual Workshop Tomorrow

by François Beerten

Hi Shebu, Will you post the slides of the presentations of the workshop ? Thanks, François. On 11/2/20 9:01 PM, Shebu Varghese Kuriakose via mbed-tls wrote: > > Hi All, > > Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, > November 3^rd ) from 2 to 6pm GMT. > > See agenda and zoom link here - > https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ > <https://www.trustedfirmware.org/meetings/mbed-tls-workshop/> > > Thanks, > > Shebu > > -----Original Appointment----- > *From:* Trusted Firmware Public Meetings > <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> > *Sent:* Friday, October 23, 2020 12:32 AM > *To:* Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; > mbed-tls(a)lists.trustedfirmware.org; Don Harbin; > psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman > *Subject:* Mbed TLS Virtual Workshop > *When:* Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, > Edinburgh, Lisbon, London. > *Where:* Zoom: > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > > > *You have been invited to the following event.* > > > Mbed TLS Virtual Workshop > > When > > > > Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix > > Where > > > > Zoom: > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > (map > <https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) > > Calendar > > > > shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com> > > Who > > > > • > > > > Don Harbin- creator > > • > > > > shebu.varghesekuriakose(a)arm.com <mailto:shebu.varghesekuriakose@arm.com> > > • > > > > mbed-tls(a)lists.trustedfirmware.org > <mailto:mbed-tls@lists.trustedfirmware.org> > > • > > > > psa-crypto(a)lists.trustedfirmware.org > <mailto:psa-crypto@lists.trustedfirmware.org> > > • > > > > dave.rodgman(a)arm.com <mailto:dave.rodgman@arm.com> > > *more details » > <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…>*** > > Hi, > Trustedfirmware.org community project would like to invite you to the > Mbed TLS Virtual Workshop. > > The purpose of the workshop is to bring together the Mbed TLS > community including maintainers, contributors and users to discuss > > * The future direction of the project and > * Ways to improve community collaboration > > Here is the agenda for the workshop. > > *Topic Time (in GMT)* > Welcome 2.00 - 2.10pm > Constant-time code 2.10 – 2.30pm > Processes - how does work get scheduled? 2.30 – 2.50pm > PSA Crypto APIs 2.50 – 3.20pm > PSA Crypto for Silicon Labs Wireless > MCUs - Why, What, Where and When 3.20 – 3.50pm > > *Break * > > Roadmap, TLS1.3 Update 4.10 – 4.30pm > Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm > How do I contribute my first review > and be an effective Mbed TLS reviewer 5.00 – 5.30pm > > Regards, > > Don Harbin > Trusted Firmware Community Manager > > > ==============Zoom details below:==================== > Trusted Firmware is inviting you to a scheduled Zoom meeting. > > Topic: Mbed TLS Virtual Workshop > Time: Nov 3, 2020 02:00 PM Greenwich Mean Time > > Join Zoom Meeting > https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… > <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> > > Meeting ID: 953 1520 0315 > Passcode: 143755 > One tap mobile > +16699009128,,95315200315# US (San Jose) > +12532158782,,95315200315# US (Tacoma) > > Dial by your location > +1 669 900 9128 US (San Jose) > +1 253 215 8782 US (Tacoma) > +1 346 248 7799 US (Houston) > +1 646 558 8656 US (New York) > +1 301 715 8592 US (Germantown) > +1 312 626 6799 US (Chicago) > 888 788 0099 US Toll-free > 877 853 5247 US Toll-free > Meeting ID: 953 1520 0315 > Find your local number: https://linaro-org.zoom.us/u/apL3hgti4 > <https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> > > Going (shebu.varghesekuriakose(a)arm.com > <mailto:shebu.varghesekuriakose@arm.com>)? *Yes > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**- > **Maybe > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>**- > **No > <https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…>*more > options » > <https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> > > Invitation from Google Calendar <https://www.google.com/calendar/> > > You are receiving this courtesy email at the account > shebu.varghesekuriakose(a)arm.com > <mailto:shebu.varghesekuriakose@arm.com> because you are an attendee > of this event. > > To stop receiving future updates for this event, decline this event. > Alternatively you can sign up for a Google account at > https://www.google.com/calendar/ and control your notification > settings for your entire calendar. > > Forwarding this invitation could allow any recipient to send a > response to the organizer and be added to the guest list, or invite > others regardless of their own invitation status, or to modify your > RSVP. Learn More > <https://support.google.com/calendar/answer/37135#forwarding>. > >

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by François Beerten

Hi, Thank you Gilles for the detailed reply. Do you prefer that discussion about PSA Crypto API spec go on mailing list instead of here ? Is there some room for evolution or is the spec already in a frozen released state ? For new algorithms, it's of course preferable that they're defined in the spec itself. But does the mbedtls project want to supports all algorithms that will be used with PSA Crypto API ? For pure ED25519 and ED448 with scattered data, there's one big gotcha. You need to generate twice a hash that includes the message. Thus the implementation needs to be able to access the buffers of the message twice. With a piece of the message given only once as in the init-update-finish scheme, that does not work well. From reading the document on the PSA Crypto driver API, a transparent driver benefits from the management of keys done by the mbedtls implementation. But what benefit is there for a driver working with opaque keys which has to fully handle the protections and restrictions of keys internally ? Best, François. On 11/2/20 11:01 PM, Gilles Peskine via mbed-tls wrote: > Hello, > > Thank you for your interest in the PSA crypto API. > > On 28/10/2020 15:20, François Beerten via mbed-tls wrote: >> Hi everybody, >> >> After reading the PSA Crypto API specs (as on >> https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) >> and looking at the mbed TLS library, a few questions came up. >> >> Is there some repository with the sources of the PSA Crypto API specs >> where one can follow the evolution and eventually send proposals and >> patches ? >> > The PSA specification drafts are not public. You can send feedback about > the PSA Crypto application and driver interfaces on the psa-crypto > mailing list (psa-crypto(a)lists.trustedfirmware.org, > https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you > prefer to send confidential feedback, you can email mbed-crypto(a)arm.com > (feedback at this address will only be discussed inside Arm). An issue > in the Mbed TLS repository will also reach PSA Crypto architects. > >> A note says "Hash suspend and resume is not defined for the SHA3 >> family of hash algorithms". Why are they not defined for SHA3 ? >> > The hash suspend/resume operations marshall the internal state of the > hash operation. They mimic an existing JavaCard API > (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). > There is a de facto standard representation of the internal state for > common Merkle-Damgård constructions, which covers all the currently > defined hash algorithms except SHA3. If there's interest in this > functionality, we could standardize a representation for SHA3. > >> How can or should one add support in PSA Crypto AP for not yet defined >> algorithms (for example a KDF) ? >> > Answer from a PSA Crypto architect: preferably by requesting an encoding > for this KDF as a PSA_ALG_xxx value (as well as new > PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do > that, use an encoding in the vendor range (most significant bit set). > > The world of key derivation functions is unfortunately messy: there are > many similar, but not functionally equivalent constructions (such as > hashing a secret together with a nonce, formatted in all kinds of > different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set > required for the TLS protocol. We expect 1.0.x updates to define more > KDF algorithms. > > Answer from an Mbed TLS maintainer: contributing an implementation would > be appreciated (but not required). > >> In multipart operations, can the user reuse the input buffers >> immediately after doing an 'update' (for example after >> psa_hash_update()) ? And can he reuse the input buffers immediately >> after some "setup" functions like psa_cipher_set_iv() or >> psa_aead_set_nonce() ? >> > Yes. PSA crypto API functions that take a buffer as a parameter never > take ownership of that buffer. Once the function returns, you can do > whatever you want with the buffer. > > The PSA specification even guarantees that you can use the same buffer, > or overlapping buffers, as inputs and outputs to the same function call. > However beware that the Mbed TLS implementation does not always support > such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). > >> Do you plan to support (pure) ED25519 and ED448 only via >> psa_sign_message() and psa_verify_message() ? What about messages in >> multiple chunks ? >> > We plan to add a multi-part message signature interface, both for the > sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I > expect the design to be “what you'd expect” but I haven't yet verified > that there aren't any gotchas. > >> In psa_asymmetric_encrypt(), why is the salt provided explicitely. >> Shouldn't it be generated randomly internally when needed ? >> > Some applications use a fixed or deterministic salt which they check on > decryption. Note that this parameter is what PKCS#1 calls “label”. > >> With PSA Crypto API, you define a flexible API for cryptographic >> operations. Apparently, other providers could make their own >> implementation of PSA Crypto API. Will mbed TLS then be able to use >> those alternate PSA Crypto API implementations ? How would that work >> practically ? >> > The X.509 and TLS layer of Mbed TLS are currently designed to use the > mbedtls_xxx crypto API. We have already added partial support for the > psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet > possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto > implementation. (I think this is already possible for a small set of > cipher suites, but it isn't something that we've tried or currently > actively support.) Before this can happen, some Mbed TLS APIs need to > change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan > to decouple the PSA crypto reference implementation (Mbed TLS's current > crypto implementation) from the X.509/TLS layer (which will remain “Mbed > TLS”). Our plans > (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far > into the future are still vague and may change. > > Note that for the most common case of wanting a different implementation > of cryptography, which is to leverage hardware such as accelerators and > secure elements, PSA is defining a driver interface which is currently > being implemented in Mbed TLS > (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). > The driver interface lets you combine mechanisms supported by your > hardware with Mbed TLS's implementation for mechanisms without hardware > support. >

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Write private key into buffer using encrypted PEM format

by Janos Follath

Hi Mate, I had a look and I couldn’t find such a feature implemented either. I don’t think that Mbed TLS supports that at the moment. Best regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Z.Máté via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Z.Máté" <enleszekakalozkiraly(a)gmail.com> Date: Monday, 2 November 2020 at 21:01 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Write private key into buffer using encrypted PEM format Dear mbedtls list members! Sorry if this is the second time I ask, I'm not sure the previous question is still on the list. I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password. In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one? For clarity, this is the type of header I'm looking for. —–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687 ………………………………………………. ………………………………………………. ……………………………………… —–END RSA PRIVATE KEY—– I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls. Yours Zombor Máté

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Gilles Peskine

Hello, Thank you for your interest in the PSA crypto API. On 28/10/2020 15:20, François Beerten via mbed-tls wrote: > > Hi everybody, > > After reading the PSA Crypto API specs (as on > https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) > and looking at the mbed TLS library, a few questions came up. > > Is there some repository with the sources of the PSA Crypto API specs > where one can follow the evolution and eventually send proposals and > patches ? > The PSA specification drafts are not public. You can send feedback about the PSA Crypto application and driver interfaces on the psa-crypto mailing list (psa-crypto(a)lists.trustedfirmware.org, https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). If you prefer to send confidential feedback, you can email mbed-crypto(a)arm.com (feedback at this address will only be discussed inside Arm). An issue in the Mbed TLS repository will also reach PSA Crypto architects. > A note says "Hash suspend and resume is not defined for the SHA3 > family of hash algorithms". Why are they not defined for SHA3 ? > The hash suspend/resume operations marshall the internal state of the hash operation. They mimic an existing JavaCard API (https://docs.oracle.com/javacard/3.0.5/api/javacard/security/InitializedMes…). There is a de facto standard representation of the internal state for common Merkle-Damgård constructions, which covers all the currently defined hash algorithms except SHA3. If there's interest in this functionality, we could standardize a representation for SHA3. > How can or should one add support in PSA Crypto AP for not yet defined > algorithms (for example a KDF) ? > Answer from a PSA Crypto architect: preferably by requesting an encoding for this KDF as a PSA_ALG_xxx value (as well as new PSA_KEY_DERIVATION_INPUT_xxx values if applicable). If you can't do that, use an encoding in the vendor range (most significant bit set). The world of key derivation functions is unfortunately messy: there are many similar, but not functionally equivalent constructions (such as hashing a secret together with a nonce, formatted in all kinds of different ways). The set of KDF in PSA Crypto 1.0.0 was the minimum set required for the TLS protocol. We expect 1.0.x updates to define more KDF algorithms. Answer from an Mbed TLS maintainer: contributing an implementation would be appreciated (but not required). > In multipart operations, can the user reuse the input buffers > immediately after doing an 'update' (for example after > psa_hash_update()) ? And can he reuse the input buffers immediately > after some "setup" functions like psa_cipher_set_iv() or > psa_aead_set_nonce() ? > Yes. PSA crypto API functions that take a buffer as a parameter never take ownership of that buffer. Once the function returns, you can do whatever you want with the buffer. The PSA specification even guarantees that you can use the same buffer, or overlapping buffers, as inputs and outputs to the same function call. However beware that the Mbed TLS implementation does not always support such overlap (https://github.com/ARMmbed/mbedtls/issues/3266). > Do you plan to support (pure) ED25519 and ED448 only via > psa_sign_message() and psa_verify_message() ? What about messages in > multiple chunks ? > We plan to add a multi-part message signature interface, both for the sake of pureEdDSA and suitable for Mbed TLS's restartable ECDSA. I expect the design to be “what you'd expect” but I haven't yet verified that there aren't any gotchas. > In psa_asymmetric_encrypt(), why is the salt provided explicitely. > Shouldn't it be generated randomly internally when needed ? > Some applications use a fixed or deterministic salt which they check on decryption. Note that this parameter is what PKCS#1 calls “label”. > With PSA Crypto API, you define a flexible API for cryptographic > operations. Apparently, other providers could make their own > implementation of PSA Crypto API. Will mbed TLS then be able to use > those alternate PSA Crypto API implementations ? How would that work > practically ? > The X.509 and TLS layer of Mbed TLS are currently designed to use the mbedtls_xxx crypto API. We have already added partial support for the psa_xxx crypto API (with MBEDTLS_USE_PSA_CRYPTO), however it is not yet possible to fully decouple the X.509/TLS layers from the Mbed TLS crypto implementation. (I think this is already possible for a small set of cipher suites, but it isn't something that we've tried or currently actively support.) Before this can happen, some Mbed TLS APIs need to change, which will happen in 2021 with Mbed TLS 3.0. After that, we plan to decouple the PSA crypto reference implementation (Mbed TLS's current crypto implementation) from the X.509/TLS layer (which will remain “Mbed TLS”). Our plans (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/) that far into the future are still vague and may change. Note that for the most common case of wanting a different implementation of cryptography, which is to leverage hardware such as accelerators and secure elements, PSA is defining a driver interface which is currently being implemented in Mbed TLS (https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-drive…). The driver interface lets you combine mechanisms supported by your hardware with Mbed TLS's implementation for mechanisms without hardware support. -- Gilles Peskine PSA Cryptography architect and Mbed TLS developer > Thank you for your attention, > > François. > > >

5 years, 4 months

1
0
0 0

Write private key into buffer using encrypted PEM format

by Z.Máté

Dear mbedtls list members! Sorry if this is the second time I ask, I'm not sure the previous question is still on the list. I'm asking if there's a way to export a private key into a buffer in an encrypted format. So that mbedtls_pk_parse_key() has to be called with a password. In the example program key_app.c (I hope that's how it's called) I can see there are password encrypted PEM formatted keys. But how to generate one? For clarity, this is the type of header I'm looking for. —–BEGIN RSA PRIVATE KEY—– Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,AB8E2B5B2D989271273F6730B6F9C687 ………………………………………………. ………………………………………………. ……………………………………… —–END RSA PRIVATE KEY—– I was only able to generate something like this by, using command line openssl. But I'd like a better solution, in code, using mbedtls. Yours Zombor Máté

5 years, 4 months

1
0
0 0

Mbed TLS Virtual Workshop Tomorrow

by Shebu Varghese Kuriakose

Hi All, Gentle reminder about the Mbed TLS workshop tomorrow (Tuesday, November 3rd) from 2 to 6pm GMT. See agenda and zoom link here - https://www.trustedfirmware.org/meetings/mbed-tls-workshop/ Thanks, Shebu -----Original Appointment----- From: Trusted Firmware Public Meetings <linaro.org_havjv2figrh5egaiurb229pd8c(a)group.calendar.google.com> Sent: Friday, October 23, 2020 12:32 AM To: Trusted Firmware Public Meetings; Shebu Varghese Kuriakose; mbed-tls(a)lists.trustedfirmware.org; Don Harbin; psa-crypto(a)lists.trustedfirmware.org; Dave Rodgman Subject: Mbed TLS Virtual Workshop When: Tuesday, November 3, 2020 2:00 PM-6:00 PM (UTC+00:00) Dublin, Edinburgh, Lisbon, London. Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… You have been invited to the following event. Mbed TLS Virtual Workshop When Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… (map<https://www.google.com/maps/search/Zoom:+https:%2F%2Flinaro-org.zoom.us%2Fj…>) Calendar shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> Who • Don Harbin - creator • shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> • mbed-tls(a)lists.trustedfirmware.org<mailto:mbed-tls@lists.trustedfirmware.org> • psa-crypto(a)lists.trustedfirmware.org<mailto:psa-crypto@lists.trustedfirmware.org> • dave.rodgman(a)arm.com<mailto:dave.rodgman@arm.com> more details »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Hi, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration Here is the agenda for the workshop. Topic Time (in GMT) Welcome 2.00 - 2.10pm Constant-time code 2.10 – 2.30pm Processes - how does work get scheduled? 2.30 – 2.50pm PSA Crypto APIs 2.50 – 3.20pm PSA Crypto for Silicon Labs Wireless MCUs - Why, What, Where and When 3.20 – 3.50pm Break Roadmap, TLS1.3 Update 4.10 – 4.30pm Mbed TLS 3.0 Plans, Scope 4.30 – 5.00pm How do I contribute my first review and be an effective Mbed TLS reviewer 5.00 – 5.30pm Regards, Don Harbin Trusted Firmware Community Manager ==============Zoom details below:==================== Trusted Firmware is inviting you to a scheduled Zoom meeting. Topic: Mbed TLS Virtual Workshop Time: Nov 3, 2020 02:00 PM Greenwich Mean Time Join Zoom Meeting https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT…<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fj%2F9531520…> Meeting ID: 953 1520 0315 Passcode: 143755 One tap mobile +16699009128,,95315200315# US (San Jose) +12532158782,,95315200315# US (Tacoma) Dial by your location +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) +1 646 558 8656 US (New York) +1 301 715 8592 US (Germantown) +1 312 626 6799 US (Chicago) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 953 1520 0315 Find your local number: https://linaro-org.zoom.us/u/apL3hgti4<https://www.google.com/url?q=https%3A%2F%2Flinaro-org.zoom.us%2Fu%2FapL3hgt…> Going (shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com>)? Yes<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - Maybe<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> - No<https://www.google.com/calendar/event?action=RESPOND&eid=NHVvY2FxY2o4Njk3MW…> more options »<https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd…> Invitation from Google Calendar<https://www.google.com/calendar/> You are receiving this courtesy email at the account shebu.varghesekuriakose(a)arm.com<mailto:shebu.varghesekuriakose@arm.com> because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn More<https://support.google.com/calendar/answer/37135#forwarding>.

5 years, 4 months

1
0
0 0

Exporting private key in encrypted PEM format

by Z.Máté

Dear mbedtls list members! Is there a way to write a private key into a buffer, in PEM format, by using a password for encryption? Mbedtls is able to parse encrypted PEM files so can I write one? I couldn't really find any info regarding it, only an older, unfinished github issue ... Yours Zombor Máté

5 years, 4 months

1
0
0 0

Re: [mbed-tls] Questions about PSA Crypto API and mbed TLS

by Levi Schuck

Hello François, The following is my understanding, I am not a maintainer but a user of mbedtls. My response below only addresses a few of your questions. PSA appears to be bound to what mbedtls currently supports, this does not include Ed25519 or Ed448 at this time. A pull request is currently open for this feature development https://github.com/ARMmbed/mbedtls/pull/3245 Further development may be necessary to include those in PSA. The only implementation of PSA that I know of is one that wraps around mbedtls. Best, Levi On Wed, Oct 28, 2020 at 9:20 AM François Beerten via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hi everybody, > > After reading the PSA Crypto API specs (as on > https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) > and looking at the mbed TLS library, a few questions came up. > > Is there some repository with the sources of the PSA Crypto API specs > where one can follow the evolution and eventually send proposals and > patches ? > > A note says "Hash suspend and resume is not defined for the SHA3 family of > hash algorithms". Why are they not defined for SHA3 ? > > How can or should one add support in PSA Crypto AP for not yet defined > algorithms (for example a KDF) ? > > In multipart operations, can the user reuse the input buffers immediately > after doing an 'update' (for example after psa_hash_update()) ? And can > he reuse the input buffers immediately after some "setup" functions like > psa_cipher_set_iv() or psa_aead_set_nonce() ? > > Do you plan to support (pure) ED25519 and ED448 only via > psa_sign_message() and psa_verify_message() ? What about messages in > multiple chunks ? > > In psa_asymmetric_encrypt(), why is the salt provided explicitely. > Shouldn't it be generated randomly internally when needed ? > > With PSA Crypto API, you define a flexible API for cryptographic > operations. Apparently, other providers could make their own implementation > of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA > Crypto API implementations ? How would that work practically ? > > Thank you for your attention, > > François. > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >

5 years, 5 months

2
2
0 0

JITR is not working in case CA is created using BouncyCastle in mbedtls

by 박현웅

I make a CA certificate for JITR using BouncyCastle lib in the android app as the below example And a device certificate is generated by this certificate in mbed_tls. At this time, JITR is not working. Namely, a device certificate is not registered in AWS. But In the case of making a ca certificate using OPENSSL, JITR works normally. Below is CA certificate based BouncyCastle lib. -----BEGIN CERTIFICATE----- MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG 6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g== -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq rEqPMGne -----END EC PRIVATE KEY----- BRs. Hyunung Park

5 years, 5 months

1
0
0 0

Questions about PSA Crypto API and mbed TLS

by François Beerten

Hi everybody, After reading the PSA Crypto API specs (as on https://armmbed.github.io/mbed-crypto/html/overview/functionality.html) and looking at the mbed TLS library, a few questions came up. Is there some repository with the sources of the PSA Crypto API specs where one can follow the evolution and eventually send proposals and patches ? A note says "Hash suspend and resume is not defined for the SHA3 family of hash algorithms". Why are they not defined for SHA3 ? How can or should one add support in PSA Crypto AP for not yet defined algorithms (for example a KDF) ? In multipart operations, can the user reuse the input buffers immediately after doing an 'update' (for example after psa_hash_update()) ? And can he reuse the input buffers immediately after some "setup" functions like psa_cipher_set_iv() or psa_aead_set_nonce() ? Do you plan to support (pure) ED25519 and ED448 only via psa_sign_message() and psa_verify_message() ? What about messages in multiple chunks ? In psa_asymmetric_encrypt(), why is the salt provided explicitely. Shouldn't it be generated randomly internally when needed ? With PSA Crypto API, you define a flexible API for cryptographic operations. Apparently, other providers could make their own implementation of PSA Crypto API. Will mbed TLS then be able to use those alternate PSA Crypto API implementations ? How would that work practically ? Thank you for your attention, François.

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Janos Follath

Hi Frank, The issue exists because you are downloading a tag and not the release. The 2.16.8 release is available here: https://github.com/ARMmbed/mbedtls/archive/v2.16.8.tar.gz Best regards, Janos On 28/10/2020, 12:15, "mbed-tls on behalf of Frank Bergmann via mbed-tls" <mbed-tls-bounces(a)lists.trustedfirmware.org on behalf of mbed-tls(a)lists.trustedfirmware.org> wrote: Hi Gilles, I noticed that the "double name" does still exist in some archive files: $ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head mbedtls-mbedtls-2.16.8/ mbedtls-mbedtls-2.16.8/.github/ mbedtls-mbedtls-2.16.8/.github/issue_template.md mbedtls-mbedtls-2.16.8/.github/pull_request_template.md mbedtls-mbedtls-2.16.8/.gitignore mbedtls-mbedtls-2.16.8/.globalrc mbedtls-mbedtls-2.16.8/.pylintrc mbedtls-mbedtls-2.16.8/.travis.yml mbedtls-mbedtls-2.16.8/CMakeLists.txt mbedtls-mbedtls-2.16.8/CONTRIBUTING.md cheers, Frank On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote: [...] > The naming with mbedtls-mbedtls- must be a bug in our release script. [...] -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 5 months

2
1
0 0

Re: [mbed-tls] Availability of 2.16.7 in download archive

by Frank Bergmann

Hi Gilles, I noticed that the "double name" does still exist in some archive files: $ wget -q -O - https://github.com/ARMmbed/mbedtls/archive/mbedtls-2.16.8.tar.gz|tar tzf -|head mbedtls-mbedtls-2.16.8/ mbedtls-mbedtls-2.16.8/.github/ mbedtls-mbedtls-2.16.8/.github/issue_template.md mbedtls-mbedtls-2.16.8/.github/pull_request_template.md mbedtls-mbedtls-2.16.8/.gitignore mbedtls-mbedtls-2.16.8/.globalrc mbedtls-mbedtls-2.16.8/.pylintrc mbedtls-mbedtls-2.16.8/.travis.yml mbedtls-mbedtls-2.16.8/CMakeLists.txt mbedtls-mbedtls-2.16.8/CONTRIBUTING.md cheers, Frank On Tue, Aug 04, 2020 at 09:18:56PM +0000, Gilles Peskine via mbed-tls wrote: [...] > The naming with mbedtls-mbedtls- must be a bug in our release script. [...] -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years, 5 months

1
0
0 0

Re: [mbed-tls] About mbedtls CVE

by Janos Follath

Hi Sawyer, Thank you for your interest in Mbed TLS. Currently the status of these CVE’s is: - CVE-2020-16150 has been fixed in the latest Mbed TLS release - CVE-2018-1000520 is not a security issue, it had been studied and rejected - CVE-2016-3739 is a vulnerability in an application using Mbed TLS but not in Mbed TLS itself, also it too had been fixed. Does this answer your question? (Also, I would like to make a minor clarification: we are not Arm Support. As far as I know Arm does not offer official support for Mbed TLS. Arm only contributes engineers to the Mbed TLS project, and at the moment these engineers are the maintainers of Mbed TLS. We are on this mailing list and try to answer questions, but we are not doing that as official support provided by Arm, but as members of the community. Mbed TLS is supported by the community and this mailing list is indeed the right place to get that support. I apologise for the nitpick, I just wanted to make sure that we are not giving the wrong impressions.) Best regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Sawyer Liu via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Sawyer Liu <sawyer.liu(a)nxp.com> Date: Wednesday, 28 October 2020 at 01:59 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] About mbedtls CVE Hello ARM Support, About below CVEs, any update? Thanks. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739 Best Regards Sawyer Liu Microcontrollers, NXP Semiconductors

5 years, 5 months

2
2
0 0

Re: [mbed-tls] JITR in mbedtls

by 박현웅

From: 박현웅 <hupark(a)ictk.com> Sent: Wednesday, October 28, 2020 6:21 PM To: 'mbed-tls(a)lists.trustedfirmware.org.' <mbed-tls(a)lists.trustedfirmware.org.> Subject: JITR in mbedtls Hi I make a certificate using BouncyCastle lib in android app as the below. JITR is not working. Namely a device certificate is not registered in aws iot. In case of making ca certificate using openssl, JITR works normally. Could you please help me? -----BEGIN CERTIFICATE----- MIIB8jCCAZegAwIBAgIVAK0ct2HFXVdS/k2NblxYGoxyuabfMAoGCCqGSM49BAMC MDIxCzAJBgNVBAYTAktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdh em9uZTAeFw0yMDEwMjcwMDAwMDBaFw0zNTAxMDEwMDAwMDBaMDIxCzAJBgNVBAYT AktSMRAwDgYDVQQKDAdUcnVzdEZpMREwDwYDVQQDDAhtZWdhem9uZTBZMBMGByqG SM49AgEGCCqGSM49AwEHA0IABEknYdqI3CdVlmMkTmqKS63HnHc5PbyBff1RokGG 6NE6z31ilA8Yt2fGFHIln1kQtx//6stBA1bIqiqsSo8wad6jgYkwgYYwHQYDVR0O BBYEFBHaQtHvagaDPkpWxQurErTekm2cMB8GA1UdIwQYMBaAFBHaQtHvagaDPkpW xQurErTekm2cMA8GA1UdEwEB/wQFMAMBAf8wEQYJYIZIAYb4QgEBBAQDAgAHMAsG A1UdDwQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDAzAKBggqhkjOPQQDAgNJADBG AiEA9HSXn3FpGUYLagsI3qaHz3VicMSuADUz/QBYEKN9STkCIQC+8BX/TPADpPOy ClmBIkjxdDt0Fh7HTDn9UwBUxYA3/g== -----END CERTIFICATE----- -----BEGIN EC PRIVATE KEY----- MIGTAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBHkwdwIBAQQgU9pUZUfplZyhC+mH Pt8pthLItdpbJ+Qy47r7gJKTNvCgCgYIKoZIzj0DAQehRANCAARJJ2HaiNwnVZZj JE5qikutx5x3OT28gX39UaJBhujROs99YpQPGLdnxhRyJZ9ZELcf/+rLQQNWyKoq rEqPMGne -----END EC PRIVATE KEY----- BRs. Hyunung Park

5 years, 5 months

1
0
0 0

About mbedtls CVE

by Sawyer Liu

Hello ARM Support, About below CVEs, any update? Thanks. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16150<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre…> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000520 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3739 Best Regards Sawyer Liu Microcontrollers, NXP Semiconductors

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Availability of GPLv2 releases in the future

by Gilles Peskine

Hi Fabian, Unfortunately https://tls.mbed.org/how-to-get is out of date. As indicated on https://tls.mbed.org/download, newer releases (since 2.17) are distributed under Apache license only. Only the long-time support branches (2.7.x and 2.16.x) still have GPL releases. -- Gilles Peskine Mbed TLS developer On 20/10/2020 14:19, Fabian Keil via mbed-tls wrote: > Hi, > > tls.mbed.org currently sends mixed signals regarding > the license of future MbedTLS releases. > > Quoting https://tls.mbed.org/download: > | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are > | available in both an Apache 2.0 licensed version (our > | primary open source license) and in a GPL 2.0 licensed version. > | > | Newer versions will be available under the Apache 2.0 license. > > Quoting https://tls.mbed.org/how-to-get: > | All the current versions of the mbed TLS library are distributed > | under the Apache 2.0 license and available from our Download area. > | In addition there are packaged versions of the mbed TLS library > | that are distributed with the GNU Public License Version 2.0 (GPL v2.0). > | > | The Apache-licensed and GPL-licensed versions of mbed TLS are > | identical in source code (with the exception of the license > | headers at the top of files). > | > | We plan to keep both licensed versions around. > > Can anyone estimate when "newer releases" will no longer > be dual licensed? > > We recently added MbedTLS support for Privoxy and a > MbedTLS license switch from dual license to Apache 2.0 > complicates the license terms. > > Thanks > Fabian >

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Clarification regarding the mbedtls_pk_context object and the PEM format, an a question about the example TLS server

by Gilles Peskine

Hi Máté, On 26/10/2020 12:04, Z.Máté via mbed-tls wrote: > Dear mbedtls mailing list members! > > I hope you recieve my message now, previously I had problems posting > to this list. :( > > My first question is actually about the PEM format. As far as I'm > aware the PEM format either contains the Private key (signalled by the > ---- BEGIN PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC > KEY -----). In my application I have to work on an app that stores key > pairs in a special, secure storage solution (Secure Storage of OPTEE > if you've heard about it). I decided to export the keys in PEM format, > so that reading and handling them is equal to moving a large string > buffer around. Using the PEM format, is there a way to store both > private and public keys in the same "file"? Does mbedtls allow for > such a solution (does such a solution even exist?). There are actually several PEM formats. Some private key formats actually store both the private key and the public key, while others only store the private key. However, it is always possible to calculate the public key from the private key. So if you want to have the whole key pair, just write the private key in any format. If you have a private key file, you can extract the public key with the Mbed TLS sample program key_app_writer (untested command line, typed directly into my mail client): programs/pkey/key_app_writer mode=private filename=my_private_key.pem output_mode=public output_file=my_public_key.pem or with OpenSSL: openssl pkey -in my_private_key.pem -pubout -out my_public_key.pem > > If not, is there a simple way to get the public key from a private key > object? Does the mbedtls_pk_context, (that parsed up with a private > key) contain the information needed to export the public key into a > PEM buffer? As far as I know mbedtls allows for exporting the private > key and the public key with the functions mbedtls_write_key_pem and > ...write_pubkey_pem (or something along those lines) does that mean I > can only export one at a time and there's no way to save the > information for both into one PEM buffer? > > If there's a way to save both private and public keys into one PEM > file, do I have to parse the private key and public key into separate > objects then? With parse_key and parse_pubkey? This isn't really a > problem just clarifying. Once you have an mbedtls_pk_context, if you want to export both keys to a file, use mbedtls_write_key_pem(). If you want to have a separate file that only contains the public key, call mbedtls_write_pubkey_pem() on the same mbedtls_pk_context. > > If you can point me to an actually good description of the PEM format > and what CAN be stored inside of it, I'd be very grateful! :) PEM is just an encoding: base64 data between a header and footer. The base64-encoded data can have several different formats depending on the header. It can represent a private key (several formats depending on the header), a public key or a certificate. A complete description is spread across about half a dozen RFC. Fortunately, I don't think you need to dig into those. > > I also have a question regarding the example SSL server program. In > it, the server needs a private key and a certificate for obvious > reasons. It also loads a certificate and as far as I know, the > certificate has to be tied to a known CA for it to be valid. > > I would like to test the program with a self generated key pair, do I > need to change the Certificate and CAs to a new one as well? To > authenticate the new keypair? Does the mbedtls ssl_client1 example > program work with self signed certs? Or do I need to take care of the > CA validation myself (that would probably beyond the scope of the > project I'm working on). The sample program ssl_server does not check the client certificate. The test program ssl_server2 can check the client certificate: pass the command line options "auth_mode=required ca_file=my_ca.crt". If you have a self-signed client certificate, you can pass it as the ca_file. -- Gilles Peskine Mbed TLS developer > > Thank you in advance! > > Yours truly, > Máté Zombor >

5 years, 5 months

1
0
0 0

Clarification regarding the mbedtls_pk_context object and the PEM format, an a question about the example TLS server

by Z.Máté

Dear mbedtls mailing list members! I hope you recieve my message now, previously I had problems posting to this list. :( My first question is actually about the PEM format. As far as I'm aware the PEM format either contains the Private key (signalled by the ---- BEGIN PRIVATE KEY ---- header) or a public key (---- BEGIN PUBLIC KEY -----). In my application I have to work on an app that stores key pairs in a special, secure storage solution (Secure Storage of OPTEE if you've heard about it). I decided to export the keys in PEM format, so that reading and handling them is equal to moving a large string buffer around. Using the PEM format, is there a way to store both private and public keys in the same "file"? Does mbedtls allow for such a solution (does such a solution even exist?). If not, is there a simple way to get the public key from a private key object? Does the mbedtls_pk_context, (that parsed up with a private key) contain the information needed to export the public key into a PEM buffer? As far as I know mbedtls allows for exporting the private key and the public key with the functions mbedtls_write_key_pem and ...write_pubkey_pem (or something along those lines) does that mean I can only export one at a time and there's no way to save the information for both into one PEM buffer? If there's a way to save both private and public keys into one PEM file, do I have to parse the private key and public key into separate objects then? With parse_key and parse_pubkey? This isn't really a problem just clarifying. If you can point me to an actually good description of the PEM format and what CAN be stored inside of it, I'd be very grateful! :) I also have a question regarding the example SSL server program. In it, the server needs a private key and a certificate for obvious reasons. It also loads a certificate and as far as I know, the certificate has to be tied to a known CA for it to be valid. I would like to test the program with a self generated key pair, do I need to change the Certificate and CAs to a new one as well? To authenticate the new keypair? Does the mbedtls ssl_client1 example program work with self signed certs? Or do I need to take care of the CA validation myself (that would probably beyond the scope of the project I'm working on). Thank you in advance! Yours truly, Máté Zombor

5 years, 5 months

1
0
0 0

Invitation: Mbed TLS Virtual Workshop @ Tue Nov 3, 2020 7am - 11am (MST) (mbed-tls@lists.trustedfirmware.org)

by Don Harbin

You have been invited to the following event. Title: Mbed TLS Virtual Workshop Hi,Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discussThe future direction of the project andWays to improve community collaborationHere is the agenda for the workshop.Topic                                                                         Time (in GMT)Welcome                                                                   2.00 - 2.10pmConstant-time code                                                2.10 – 2.30pmProcesses - how does work get scheduled?      2.30 – 2.50pmPSA Crypto APIs                                                     2.50 – 3.20pmPSA Crypto for Silicon Labs Wireless         MCUs - Why, What, Where and When          3.20 – 3.50pmBreak                                                                          Roadmap, TLS1.3 Update                                      4.10 – 4.30pmMbed TLS 3.0 Plans, Scope                                   4.30 – 5.00pmHow do I contribute my first review         and be an effective Mbed TLS reviewer      5.00 – 5.30pmRegards,Don Harbin Trusted Firmware Community Manager==============Zoom details below:====================Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: Mbed TLS Virtual WorkshopTime: Nov 3, 2020 02:00 PM Greenwich Mean TimeJoin Zoom Meetinghttps://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT09Meeting ID: 953 1520 0315Passcode: 143755One tap mobile+16699009128,,95315200315# US (San Jose)+12532158782,,95315200315# US (Tacoma)Dial by your location        +1 669 900 9128 US (San Jose)        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 646 558 8656 US (New York)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        888 788 0099 US Toll-free        877 853 5247 US Toll-freeMeeting ID: 953 1520 0315Find your local number: https://linaro-org.zoom.us/u/apL3hgti4 When: Tue Nov 3, 2020 7am – 11am Mountain Standard Time - Phoenix Where: Zoom: https://linaro-org.zoom.us/j/95315200315?pwd=ZDJGc1BZMHZLV29DTmpGUllmMjB1UT… Calendar: mbed-tls(a)lists.trustedfirmware.org Who: * Don Harbin - creator * shebu.varghesekuriakose(a)arm.com * mbed-tls(a)lists.trustedfirmware.org * psa-crypto(a)lists.trustedfirmware.org * dave.rodgman(a)arm.com Event details: https://www.google.com/calendar/event?action=VIEW&eid=NHVvY2FxY2o4Njk3MWZkd… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account mbed-tls(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 5 months

1
0
0 0

Availability of GPLv2 releases in the future

by Fabian Keil

Hi, tls.mbed.org currently sends mixed signals regarding the license of future MbedTLS releases. Quoting https://tls.mbed.org/download: | In packaged form, mbed TLS 2.1.0 to mbed TLS 2.16 are | available in both an Apache 2.0 licensed version (our | primary open source license) and in a GPL 2.0 licensed version. | | Newer versions will be available under the Apache 2.0 license. Quoting https://tls.mbed.org/how-to-get: | All the current versions of the mbed TLS library are distributed | under the Apache 2.0 license and available from our Download area. | In addition there are packaged versions of the mbed TLS library | that are distributed with the GNU Public License Version 2.0 (GPL v2.0). | | The Apache-licensed and GPL-licensed versions of mbed TLS are | identical in source code (with the exception of the license | headers at the top of files). | | We plan to keep both licensed versions around. Can anyone estimate when "newer releases" will no longer be dual licensed? We recently added MbedTLS support for Privoxy and a MbedTLS license switch from dual license to Apache 2.0 complicates the license terms. Thanks Fabian

5 years, 5 months

1
0
0 0

Fwd: Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hi Dave, Thanks for your reply. The particular reasons for bringing up 2.7 and 2.16 first is that my employer is currently using 2.7 and would prefer using a small increment. Having said that, if adding features to LTS is not advisable (especially given that 2.7 has less than 6 months of projected life), I think I can present the arguments against using the 2.7. Additional consideration is the timing. My employer needs fragmentation support as soon as possible, with the intent of running it on a desktop environment. Historically, when the engineers are able to provide my employer with what is needed now, they are allowed more time for incremental improvements. The third consideration involves the MPS project by Hanno Becker. I've been collaborating with Hanno, and with Hannes Tschofenig and Thomas Fosetti on the project of adding QUIC support to mbedTLS. This goal depends on TLS 1.3 support (Hannes has written a prototype, which I was able to add QUIC in an internal version), and on MPS. I would like to avoid putting a duplicate effort into non-MPS fragmentation support. Unfortunately, if I want to meet the timing requirements of my employer, I will not be able to use MPS, since it needs more maturing. Because of the above considerations, I would like to suggest the following plan of actions: As the first step, I would like to add the MVP (minimal viable product) fragmentation to the development version. The MVP takes the following assumptions: 1. The RAM footprint is not a concern for the MVP (my employer is going to run it in the desktop environment). 2. Unification of the fragmentation between TLS and DTLS is not a concern for the MVP 3. LTS is not a concern for the MVP (potentially not at all) Because of the above simplifying assumptions, I believe that the change can be small and focused. I think I can have code ready for review in a couple of weeks. As the second step, I would like to put my effort into helping Hanno Becker with his MPS system. Once sufficiently mature, the MPS will supersede the MVP fragmentation, and will open the doors for adding support for QUIC. The simplifying assumptions 1. (RAM) and 2. (TLS <=> DTLS) will be addressed by MPS. Addressing the last assumption may not be required. What are your thoughts? On Wed, Oct 14, 2020 at 10:28 AM Dave Rodgman <dave.rodgman(a)arm.com> wrote: > Hi Omer, > > > > Thanks for offering to help us with this feature. > > > > Normally, we wouldn’t add new features directly to an older branch, for a > few reasons. 2.7 is quite old and is in fact only guaranteed to be > supported until Feb 21, so it’s not the ideal place to spend effort on new > features. Introducing new features here would also create the situation > where 2.7 has features not in development, and vice-versa, creating an > upgrade dilemma for users (unless we were to port the feature to all > supported branches). And adding significant new features to LTS branches > can always introduce some risk of destabilising it. > > > > So for these reasons, we would normally recommend targeting the > development branch for new features (with backports only where there is a > strong reason to do so), and then picking up the next stable release that > contains the new feature. > > > > Is there a particular reason you’re focusing on 2.7, rather than > development, or would it be viable for you to add this to development and > pick up the next release? > > > > Thanks > > > > Dave > > > > *From: *mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf > of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Reply to: *Omer Shapira <omer.shapira(a)gmail.com> > *Date: *Monday, 12 October 2020 at 20:04 > *To: *"mbed-tls(a)lists.trustedfirmware.org" < > mbed-tls(a)lists.trustedfirmware.org> > *Subject: *[mbed-tls] Working on TLS handshake record fragmentation > (#1840) > > > > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > > Sincerely Yours, > Omer Shapira > -- Sincerely Yours, Omer Shapira -- Sincerely Yours, Omer Shapira

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Dave Rodgman

Hi Omer, Thanks for offering to help us with this feature. Normally, we wouldn’t add new features directly to an older branch, for a few reasons. 2.7 is quite old and is in fact only guaranteed to be supported until Feb 21, so it’s not the ideal place to spend effort on new features. Introducing new features here would also create the situation where 2.7 has features not in development, and vice-versa, creating an upgrade dilemma for users (unless we were to port the feature to all supported branches). And adding significant new features to LTS branches can always introduce some risk of destabilising it. So for these reasons, we would normally recommend targeting the development branch for new features (with backports only where there is a strong reason to do so), and then picking up the next stable release that contains the new feature. Is there a particular reason you’re focusing on 2.7, rather than development, or would it be viable for you to add this to development and pick up the next release? Thanks Dave From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Omer Shapira via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Omer Shapira <omer.shapira(a)gmail.com> Date: Monday, 12 October 2020 at 20:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Working on TLS handshake record fragmentation (#1840) Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

While waiting for opinions regarding the question of adding features to the LTS versions, I have written a draft design doc. I discussed the "design review process" with Hanno Becker, and we decided to try and use GitHub for the design review. I have created PR #3783 [0], which includes `docs/proposed/hs_fragmentation.md` [1]. I will appreciate your comments, and will update the design doc following the feedback. Once there is clarity on the approach, I will proceed with the implementation PRs. [0] https://github.com/ARMmbed/mbedtls/pull/3783 [1] https://github.com/ARMmbed/mbedtls/pull/3783/commits/8be34f22237ee3cd3c1db2… On Mon, Oct 12, 2020 at 12:04 PM Omer Shapira via mbed-tls < mbed-tls(a)lists.trustedfirmware.org> wrote: > Hello, > > My employer (Facebook) is willing to give me some time to TLS handshake > fragmentation support to MbedTLS 2.7 [0] . This would be my first > contribution to MbedTLS, and I have several novice questions: > > 1. What is the best way to add the feature to MbedTLS 2.7? > 2. Trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. > > Question 1: Best way to add the feature to MbedTLS 2.7 > > One constraint that I am facing is the code must be added to the upstream > branch that is as close as possible to the 2.7.xx. My understanding of the > Contribution Guidelines[1] is that while the LTS branches are mostly meant > for the bug fixes, backporting of the new features is welcomed as long as > the API/ABI compatibility is maintained and the disruption to the users is > minimized. > > If adding support to the LTS branches is not advisable, are there any > other possibilities of contributing the code to an upstream branch that is > very close to the 2.7.xx? > > Question 2: Trade-off between the consistency of the fragmentation code > across the branches, vs. the consistency of the branches. > > Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a > trade-off between the consistency of the fragmentation code across the > branches, vs. the consistency of the branches. The `development` branch > supports variable-length buffers[2] . Variable messages sizes would make > the fragmentation easier in the development branch. In addition, there is > the MPS effort by Hanno Becker which would make the fragmentation support > even easier in the development branch. None of that is present in the 2.7 > or the 2.16 branches. > > What is the preferable trade-off in such a situation: > a. Minimizing the change to the "host" version (2.7 or 2.16), on the > expense the implementation of the feature differ between 2.7 and > `development`, or > b. Minimizing the differences in the implementation of the feature, on > the expense of more intrusive changes to the earlier versions? > > > [0] https://github.com/ARMmbed/mbedtls/issues/1840 > [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md > [2] > https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… > > -- > Sincerely Yours, > Omer Shapira > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > -- Sincerely Yours, Omer Shapira

5 years, 5 months

1
0
0 0

Working on TLS handshake record fragmentation (#1840)

by Omer Shapira

Hello, My employer (Facebook) is willing to give me some time to TLS handshake fragmentation support to MbedTLS 2.7 [0] . This would be my first contribution to MbedTLS, and I have several novice questions: 1. What is the best way to add the feature to MbedTLS 2.7? 2. Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Question 1: Best way to add the feature to MbedTLS 2.7 One constraint that I am facing is the code must be added to the upstream branch that is as close as possible to the 2.7.xx. My understanding of the Contribution Guidelines[1] is that while the LTS branches are mostly meant for the bug fixes, backporting of the new features is welcomed as long as the API/ABI compatibility is maintained and the disruption to the users is minimized. If adding support to the LTS branches is not advisable, are there any other possibilities of contributing the code to an upstream branch that is very close to the 2.7.xx? Question 2: Trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. Assuming that adding features to 2.7 (and 2.16) *is* possible, there is a trade-off between the consistency of the fragmentation code across the branches, vs. the consistency of the branches. The `development` branch supports variable-length buffers[2] . Variable messages sizes would make the fragmentation easier in the development branch. In addition, there is the MPS effort by Hanno Becker which would make the fragmentation support even easier in the development branch. None of that is present in the 2.7 or the 2.16 branches. What is the preferable trade-off in such a situation: a. Minimizing the change to the "host" version (2.7 or 2.16), on the expense the implementation of the feature differ between 2.7 and `development`, or b. Minimizing the differences in the implementation of the feature, on the expense of more intrusive changes to the earlier versions? [0] https://github.com/ARMmbed/mbedtls/issues/1840 [1] https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md [2] https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.… -- Sincerely Yours, Omer Shapira

5 years, 5 months

1
0
0 0

Mbed TLS Virtual Workshop on Nov. 3rd

by Shebu Varghese Kuriakose

Hi All, Trustedfirmware.org community project would like to invite you to the Mbed TLS Virtual Workshop on November 3rd (Tuesday) from 2pm to 6pm GMT. The purpose of the workshop is to bring together the Mbed TLS community including maintainers, contributors and users to discuss * The future direction of the project and * Ways to improve community collaboration The workshop will be hosted in Zoom open to all. The invitation with the zoom link will be send in the Mbed TLS, PSA Crypto* mailing lists in the coming days. Here are some of the proposed agenda topics. Please reply if there is anything else you would like us or you to present during the workshop that will be interesting to the community * Constant-time code * How to be an effective Mbed TLS reviewer * Processes - how does work get scheduled? * Roadmap, Mbed TLS3.0 * PSA Crypto APIs * How Do I contribute my first review. Thanks, Shebu (TrustedFirmware.org Co-Chair, Mbed TLS Technology Manager) * https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Official bug list

by Janos Follath

Hi Innocenti, The official list of defects is available on github: https://github.com/ARMmbed/mbedtls/issues?q=is%3Aissue+is%3Aopen+label%3Abug The revision of fixing is in the Bugfix sections of the ChangeLog file in the source. Eg. for the latest release: https://github.com/ARMmbed/mbedtls/blob/mbedtls-2.24.0/ChangeLog The entries here usually reference the issue number they fixed. Is this something that you can use for your evaluation? Regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of "Innocenti, Michele via mbed-tls" <mbed-tls(a)lists.trustedfirmware.org> Reply to: "Innocenti, Michele" <michele_innocenti(a)baxter.com> Date: Thursday, 1 October 2020 at 14:04 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Official bug list Hi, We are evaluating Mbed TLS library and we need to know if it’s available an official list of defects and revision of fixing. I’m not looking for CVEs but for bugs in the library. Thanks! Michele

5 years, 5 months

1
0
0 0

Official bug list

by Innocenti, Michele

Hi, We are evaluating Mbed TLS library and we need to know if it's available an official list of defects and revision of fixing. I'm not looking for CVEs but for bugs in the library. Thanks! Michele

5 years, 5 months

1
0
0 0

Re: [mbed-tls] FIPS

by Janos Follath

Hi, There is no FIPS validated/certified version of Mbed TLS. In general most of the components should be very close to FIPS/NIST standards, but I don’t know of any that would have undergone a validation/certification process. Regards, Janos (Mbed TLS developer) From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Subramanian Gopi Krishnan via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Reply to: Subramanian Gopi Krishnan <gopikrishnan.subramanian(a)kone.com> Date: Thursday, 1 October 2020 at 07:38 To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] FIPS Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

5 years, 5 months

1
0
0 0

FIPS

by Subramanian Gopi Krishnan

Hi, Do we have FIPS compliant for mbedtls; similar to openssl fips? Thanks, Gopi Krishnan

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, actually I meant that the creator of the PR tries to make a first estimation. Maybe even this could be helpful. :-) Frank On Wed, Sep 30, 2020 at 09:47:41AM +0000, Gilles Peskine via mbed-tls wrote: > Hi Frank, > > Thanks for the suggestion. Sorry for not replying earlier. A time > estimate can help with scheduling, but our problem isn't so much > scheduling as a lack of bandwidth. Also we've found it very difficult to > estimate the time a review will take: some innocuous-looking patches end > up raising time-consuming questions about security or compatibility, > while some large patches turn out to be easy because they don't affect > risky areas much. > > The way we currently work is to schedule large contributions as part of > our sprint planning, but for most reviews we put them in a queue > (https://github.com/orgs/ARMmbed/projects/3). We've found that for our > team, having people pull from that queue works better than designating > reviewers a priori. > > -- > Gilles Peskine > Mbed TLS developer > > On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > > Hi Gilles, > > > > when I ask in our team to review a PR I usually provide an estimation about > > it. Of course a time base estimation and not an agile one in values of > > complexity. ;-) > > One could also provide an estimation about priority. > > Maybe these tiny rules may help somewhat. At least it can provide a better > > overview if you have tons of PRs. > > > > sincerely, > > Frank > > > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > >> Hello, > >> > >> Historically, Mbed TLS has been maintained by Arm as an open-source > >> project, accepting external contributions, but with with priorities and > >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > >> open governance project under the umbrella of TrustedFirmware, with the > >> objective of making it a community led project, allowing community to > >> contribute and collaborate on the design and development of the project. > >> In practice, however, the project effectively still has some barriers of > >> entry. We would like to lift these barriers. > >> > >> The Mbed TLS team at Arm have already identified some concrete actions, > >> filed on the Mbed TLS epic board > >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > >> under “Facilitating community contributions”. A few more should be up > >> soon as the result of some internal brainstorming. > >> > >> We've also identified some problem areas which we're tracking as > >> separate topics. > >> > >> * Probably the biggest topic: review was and is a bottleneck. We are > >> working to streamline the review process where possible, without > >> lowering the quality bar, and to prioritize reviews better over new > >> work. (Having personally often been on both sides of the coin, I can > >> confirm that having a pull request sit around for years without getting > >> reviews is frustrating, and so is seeing all these pull request and not > >> having the time to review them all.) We would also like to enable, > >> encourage and value reviews from people who are not project maintainers. > >> > >> * We will migrate the CI to a publicly available platform hosted by > >> TrustedFirmware. However this platform will not be available until 2021. > >> > >> * We are working on a new documentation platform, where we'll transfer > >> both the information available on the current website and information > >> that is currently recorded in an Arm internal wiki. > >> > >> To all of you who have contributed to Mbed TLS, who have tried, or who > >> are considering it, what difficulties have you encountered? What else > >> can we do to make contributing easier? > >> > >> Best regards, > >> > >> -- > >> Gilles Peskine > >> Mbed TLS developer > >> > >> > >> -- > >> mbed-tls mailing list > >> mbed-tls(a)lists.trustedfirmware.org > >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Gilles Peskine

Hi Frank, Thanks for the suggestion. Sorry for not replying earlier. A time estimate can help with scheduling, but our problem isn't so much scheduling as a lack of bandwidth. Also we've found it very difficult to estimate the time a review will take: some innocuous-looking patches end up raising time-consuming questions about security or compatibility, while some large patches turn out to be easy because they don't affect risky areas much. The way we currently work is to schedule large contributions as part of our sprint planning, but for most reviews we put them in a queue (https://github.com/orgs/ARMmbed/projects/3). We've found that for our team, having people pull from that queue works better than designating reviewers a priori. -- Gilles Peskine Mbed TLS developer On 21/09/2020 07:35, Frank Bergmann via mbed-tls wrote: > Hi Gilles, > > when I ask in our team to review a PR I usually provide an estimation about > it. Of course a time base estimation and not an agile one in values of > complexity. ;-) > One could also provide an estimation about priority. > Maybe these tiny rules may help somewhat. At least it can provide a better > overview if you have tons of PRs. > > sincerely, > Frank > > On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: >> Hello, >> >> Historically, Mbed TLS has been maintained by Arm as an open-source >> project, accepting external contributions, but with with priorities and >> plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an >> open governance project under the umbrella of TrustedFirmware, with the >> objective of making it a community led project, allowing community to >> contribute and collaborate on the design and development of the project. >> In practice, however, the project effectively still has some barriers of >> entry. We would like to lift these barriers. >> >> The Mbed TLS team at Arm have already identified some concrete actions, >> filed on the Mbed TLS epic board >> https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 >> under “Facilitating community contributions”. A few more should be up >> soon as the result of some internal brainstorming. >> >> We've also identified some problem areas which we're tracking as >> separate topics. >> >> * Probably the biggest topic: review was and is a bottleneck. We are >> working to streamline the review process where possible, without >> lowering the quality bar, and to prioritize reviews better over new >> work. (Having personally often been on both sides of the coin, I can >> confirm that having a pull request sit around for years without getting >> reviews is frustrating, and so is seeing all these pull request and not >> having the time to review them all.) We would also like to enable, >> encourage and value reviews from people who are not project maintainers. >> >> * We will migrate the CI to a publicly available platform hosted by >> TrustedFirmware. However this platform will not be available until 2021. >> >> * We are working on a new documentation platform, where we'll transfer >> both the information available on the current website and information >> that is currently recorded in an Arm internal wiki. >> >> To all of you who have contributed to Mbed TLS, who have tried, or who >> are considering it, what difficulties have you encountered? What else >> can we do to make contributing easier? >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> >> -- >> mbed-tls mailing list >> mbed-tls(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 5 months

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, We're going ahead with this new process. For changes made since the last release (2.24.0 and corresponding updates to long-time support branches), the ChangeLog file will only record user-visible changes, and entries will not be used to credit contributors. We're updating ChangeLog.d/00README.md accordingly (https://github.com/ARMmbed/mbedtls/pull/3726). -- Gilles Peskine Mbed TLS developer On 20/09/2020 23:41, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, >

5 years, 5 months

1
0
0 0

Information about CI failures on pull requests to Mbed TLS

by Gilles Peskine

Hello, If you've made a pull request to Mbed TLS, you've noticed that some of the continuous integration happens on a private server run by Arm. For jobs that ran since yesterday, if there are failures, you can now see the name of the failed tasks next to “PR-NNN-head TLS Testing” or “PR-NNN-merge TLS Testing”. See https://developer.trustedfirmware.org/w/mbed-tls/testing/ci/#identifying-je… for more details. If this isn't enough, an Arm employee can copy the logs from the server. Please ask in a comment. We hope to post logs automatically (https://github.com/ARMmbed/mbedtls/issues/3633) but I can't give a due date for that. We are planning to move to a public server run by TrustedFirmware, but this can't happen until some time in 2021. Please bear with us in the meantime, and thank you for your contributions. -- Gilles Peskine Mbed TLS developer

5 years, 5 months

1
0
0 0

MbedTLS Webserver

by Thomas Schwarz

Hello everyone, I want to set up a webserver on my ESP32 Dev Module based von MbedTLS. Therefore I view the ssl_server example on github. Now my question: How can I connect the ssl_server to my local WIFI-network. What extra code do I need? And where is the SSID and the password configurable? Thanks for your help! Best regards Thomas Tel.: +49833460134418 MULTIVAC Info Box MULTIVAC Sepp Haggenmüller SE & Co. KG - Bahnhofstr. 4 - D-87787 Wolfertschwenden - Germany Tel.: +49(0)8334/601-0 - Fax: +49(0)8334/601-199 - multivac(a)multivac.de Kommanditgesellschaft Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRA 8040 USt-IdNr.: DE 129082475 - Steuer-Nr.: 138/169/51105 - WEEE-Reg.-Nr.: DE 16576440 Persönlich haftende Gesellschafterin: MULTIVAC Sepp Haggenmüller Verwaltungs SE Sitz: 87787 Wolfertschwenden Amtsgericht: Memmingen HRB 16659 Geschäftsführende Direktoren: Guido Spix, Christian Traumann Verwaltungsratsvorsitzender: Elmar Fischer Bankverbindung: Deutsche Bank Memmingen . IBAN: DE 31 7337 0008 0123 6330 00 . BIC: DEUT DE MM 733 Banner

5 years, 6 months

1
0
0 0

DTLS server

by Mehdi Karimi

I am using v16 of the mbedTLS library to setup DTLS server. However, I observe that the handshake does not work well and there are several issues starting with the cookie exchange. Do I necessarily have to update to the latest version of mbedTLS? Are there known issues with DTLS server setup using previous versions (as far as I could tell from the ChangeLog). Thanks Mehdi

5 years, 6 months

1
0
0 0

Re: [mbed-tls] Proposed change: no longer credit contributors in the ChangeLog file

by Frank Bergmann

Hi Gilles, as you said: Git is public. As long as it is kept public there's no reason to "duplicate details". My 2 cents. sincerely, Frank On Sun, Sep 20, 2020 at 09:41:26PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > The Mbed TLS team is soliciting feedback on a proposed change of our > contributor acknowledgement policy. > > Background: our current policy is to acknowledge all contributors who > are not Arm employees in the ChangeLog files. This is a tradition that > dates back from when the version control history of Mbed TLS (then > PolarSSL) was not public. > > Proposed change: the ChangeLog file will no longer mention who > contributed a patch (“Contributed by …”). A patch will require a > ChangeLog entry only if it makes a user-visible changes, regardless of > who contributed it. We will still credit reporters in the ChangeLog > file, at least for security issues. > > Rationale: the ChangeLog file had a dual purpose: informing users, and > acknowledging contributors. It will now have the single purpose of > informing users. There are better ways of acknowledging contributors > nowadays: the Git history is public, and your contributions are visible > from your GitHub profile. (Note that we don't squash commits, and > attempt to preserve authorship as much as possible when we have to > rebase a patch.) Furthermore, writing a good ChangeLog entry often turns > out to require some back-and-forth, so lessening this requirement will > make it easier to accept contributions and to merge them faster (this is > in fact our primary motivation for the change). > > We are also thinking of creating an acknowledgement page out-of-tree. It > isn't clear yet what its scope would be, but it would include > acknowledging contributions in the form of reviews, which we wish to > encourage. (Please stay tuned for future announcements and discussions > regarding the Mbed TLS review process.) > > Question to potential contributors, or people who have participated in > other open-source projects: do you think that there is any value in > keeping acknowledgements in a file that is distributed with Mbed TLS? Is > there any value in maintaining an exhaustive list of contributors in a > form other than the Git history? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years, 6 months

1
0
0 0

Re: [mbed-tls] Building a collaborative Mbed TLS community

by Frank Bergmann

Hi Gilles, when I ask in our team to review a PR I usually provide an estimation about it. Of course a time base estimation and not an agile one in values of complexity. ;-) One could also provide an estimation about priority. Maybe these tiny rules may help somewhat. At least it can provide a better overview if you have tons of PRs. sincerely, Frank On Sun, Sep 20, 2020 at 10:27:44PM +0000, Gilles Peskine via mbed-tls wrote: > Hello, > > Historically, Mbed TLS has been maintained by Arm as an open-source > project, accepting external contributions, but with with priorities and > plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an > open governance project under the umbrella of TrustedFirmware, with the > objective of making it a community led project, allowing community to > contribute and collaborate on the design and development of the project. > In practice, however, the project effectively still has some barriers of > entry. We would like to lift these barriers. > > The Mbed TLS team at Arm have already identified some concrete actions, > filed on the Mbed TLS epic board > https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 > under “Facilitating community contributions”. A few more should be up > soon as the result of some internal brainstorming. > > We've also identified some problem areas which we're tracking as > separate topics. > > * Probably the biggest topic: review was and is a bottleneck. We are > working to streamline the review process where possible, without > lowering the quality bar, and to prioritize reviews better over new > work. (Having personally often been on both sides of the coin, I can > confirm that having a pull request sit around for years without getting > reviews is frustrating, and so is seeing all these pull request and not > having the time to review them all.) We would also like to enable, > encourage and value reviews from people who are not project maintainers. > > * We will migrate the CI to a publicly available platform hosted by > TrustedFirmware. However this platform will not be available until 2021. > > * We are working on a new documentation platform, where we'll transfer > both the information available on the current website and information > that is currently recorded in an Arm internal wiki. > > To all of you who have contributed to Mbed TLS, who have tried, or who > are considering it, what difficulties have you encountered? What else > can we do to make contributing easier? > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls -- Frank Bergmann, Pödinghauser Str. 5, D-32051 Herford, Tel. +49-5221-9249753 SAP Hybris & Linux LPIC-3, E-Mail tx2014(a)tuxad.de, USt-IdNr DE237314606 http://tdyn.de/freel -- Redirect to profile at freelancermap http://www.gulp.de/freiberufler/2HNKY2YHW.html -- Profile at GULP

5 years, 6 months

1
0
0 0

Building a collaborative Mbed TLS community

by Gilles Peskine

Hello, Historically, Mbed TLS has been maintained by Arm as an open-source project, accepting external contributions, but with with priorities and plans mostly driven only by Arm. Since earlier this year, Mbed TLS is an open governance project under the umbrella of TrustedFirmware, with the objective of making it a community led project, allowing community to contribute and collaborate on the design and development of the project. In practice, however, the project effectively still has some barriers of entry. We would like to lift these barriers. The Mbed TLS team at Arm have already identified some concrete actions, filed on the Mbed TLS epic board https://github.com/ARMmbed/mbedtls/projects/2#column-10667107 under “Facilitating community contributions”. A few more should be up soon as the result of some internal brainstorming. We've also identified some problem areas which we're tracking as separate topics. * Probably the biggest topic: review was and is a bottleneck. We are working to streamline the review process where possible, without lowering the quality bar, and to prioritize reviews better over new work. (Having personally often been on both sides of the coin, I can confirm that having a pull request sit around for years without getting reviews is frustrating, and so is seeing all these pull request and not having the time to review them all.) We would also like to enable, encourage and value reviews from people who are not project maintainers. * We will migrate the CI to a publicly available platform hosted by TrustedFirmware. However this platform will not be available until 2021. * We are working on a new documentation platform, where we'll transfer both the information available on the current website and information that is currently recorded in an Arm internal wiki. To all of you who have contributed to Mbed TLS, who have tried, or who are considering it, what difficulties have you encountered? What else can we do to make contributing easier? Best regards, -- Gilles Peskine Mbed TLS developer

5 years, 6 months

1
0
0 0

Proposed change: no longer credit contributors in the ChangeLog file

by Gilles Peskine

Hello, The Mbed TLS team is soliciting feedback on a proposed change of our contributor acknowledgement policy. Background: our current policy is to acknowledge all contributors who are not Arm employees in the ChangeLog files. This is a tradition that dates back from when the version control history of Mbed TLS (then PolarSSL) was not public. Proposed change: the ChangeLog file will no longer mention who contributed a patch (“Contributed by …”). A patch will require a ChangeLog entry only if it makes a user-visible changes, regardless of who contributed it. We will still credit reporters in the ChangeLog file, at least for security issues. Rationale: the ChangeLog file had a dual purpose: informing users, and acknowledging contributors. It will now have the single purpose of informing users. There are better ways of acknowledging contributors nowadays: the Git history is public, and your contributions are visible from your GitHub profile. (Note that we don't squash commits, and attempt to preserve authorship as much as possible when we have to rebase a patch.) Furthermore, writing a good ChangeLog entry often turns out to require some back-and-forth, so lessening this requirement will make it easier to accept contributions and to merge them faster (this is in fact our primary motivation for the change). We are also thinking of creating an acknowledgement page out-of-tree. It isn't clear yet what its scope would be, but it would include acknowledging contributions in the form of reviews, which we wish to encourage. (Please stay tuned for future announcements and discussions regarding the Mbed TLS review process.) Question to potential contributors, or people who have participated in other open-source projects: do you think that there is any value in keeping acknowledgements in a file that is distributed with Mbed TLS? Is there any value in maintaining an exhaustive list of contributors in a form other than the Git history? Best regards, -- Gilles Peskine Mbed TLS developer

5 years, 6 months

1
0
0 0

Parse RSA keyfile-Error

by youssouf sokhona

Good morning to all, I am currently trying to perform RSA encryption, so I am using a file containing a public key (generated by OpenSSL) to do this. So at the beginning I use the "mbedtls_pk_parse_keyfile" function to read it, as you can see on the image below. Unfortunately, I find the following error : ERROR 3E00 : Read/write of file failed. Do someone have an idea of why I have this error ? Or should I change my way to read this file ? Thanks a lot, have a nice Weekend [cid:image002.png@01D68839.7B058100]

5 years, 6 months

1
0
0 0

Re: [mbed-tls] Query related to ARM - MbedTLS

by Manu Abraham

Hi, Unrelated comment from my side, adding on to Manuel's comment: It appears that ST supplies a binary blob which does make use of their hardware crypto accelerator. https://www.st.com/en/embedded-software/x-cube-cryptolib.html Cheers, Manu On Wed, Sep 9, 2020 at 1:21 PM Manuel Pegourie-Gonnard via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> wrote: > > Hi, > > On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well. > > Regards, > Manuel. > ________________________________ > From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > Sent: 09 September 2020 08:32 > To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> > Subject: [mbed-tls] Query related to ARM - MbedTLS > > Hi, > > I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. > > I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. > > Looking forward to hearing from you. > > > Best regards, > Hafiz Areeb Asad > -- > mbed-tls mailing list > mbed-tls(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

5 years, 6 months

2
1
0 0

Re: [mbed-tls] Query related to ARM - MbedTLS

by Manuel Pegourie-Gonnard

Hi, On those CPUs, the AES implementation in Mbed TLS is pure C, it doesn't use any hand-written assembly. The only platforms where it does so so far are x86-64 (to take advantage of the AES-NI extension if available), and some Via CPUs (x86) that have AES acceleration as well. Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Areeb Asad via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 09 September 2020 08:32 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Query related to ARM - MbedTLS Hi, I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. Looking forward to hearing from you. Best regards, Hafiz Areeb Asad

5 years, 6 months

1
0
0 0

Query related to ARM - MbedTLS

by Areeb Asad

Hi, I hope you are doing well. I am using the mbedTLS AES library in my projects, part of my master thesis at Uppsala University. I would like to know whether the mbedTLS AES library uses any assemble specific code for operations? I am using this library on Cortex-M23 and Cortex M0+. Looking forward to hearing from you. Best regards, Hafiz Areeb Asad

5 years, 6 months

1
0
0 0

A new configuration mechanism for PSA crypto in Mbed TLS

by Gilles Peskine

Hello, As you may be aware, there is work in progress to implement support for hardware drivers in Mbed TLS when using the PSA API. These are direct calls from the PSA frontend layer to driver code, without going through mbedtls_xxx APIs and the ALT implementations. The specifications are the psa-driver-*.md files in https://github.com/ARMmbed/mbedtls/tree/development/docs/proposed and you can watch the work in progress in the “Unified driver interface: API design and prototype” epic https://github.com/ARMmbed/mbedtls/projects/2#column-8543266 . When an algorithm is implemented in hardware, in most cases, it is unnecessary to include a software implementation, and it should be possible to exclude the software implementation from the build to keep the code size down. Unfortunately the current Mbed TLS configuration mechanism does not support this, because it does not distinguish “I want AES” from “I want mbedtls_aes_xxx”. So we need new compile-time options to convey “I want PSA_KEY_TYPE_AES in my application but I don't care whether it's done in hardware or mbedtls_aes_xxx”. We are going to implement a configuration mechanism to select which cryptographic algorithms are included in the PSA interface in a build of Mbed TLS. It will rely on #define statements, like the existing config.h, but with different naming conventions for PSA. You can see the specification proposal at https://github.com/ARMmbed/mbedtls/pull/3628 . Feedback is welcome. We're likely to merge this pull request soon, but even after it's merged I'll keep watching comments, or you can post feedback on the mailing list, or raise an issue on GitHub if you have a specific feature request. A major difference between the current MBEDTLS_xxx_C configuration and the new PSA_WANT_xxx configuration is that PSA_WANT_xxx is additive: if PSA_WANT_xxx depends on some other feature, enabling PSA_WANT_xxx will automatically enable that feature in most cases (the exception being when there's more than one way to enable the dependent feature, e.g. when a hash algorithm is needed but it doesn't matter which hash). This is in contrast with the current strict mechanism where enabling MBEDTLS_xxx_C is an error if it depends on some other feature that isn't enabled. We haven't decided yet, but we're thinking of changing to an additive mechanism for the whole Mbed TLS configuration in Mbed TLS 3.0. If you want to watch the implementation work in progress, it will be under the “Driver Interface: Removing unused code” epic https://github.com/ARMmbed/mbedtls/projects/2#column-9449707 . Note that the #define-based mechanism is somewhat experimental and we won't commit yet about its long-term stability in Mbed TLS. It is likely to be complemented by a JSON-based mechanism in the future. This JSON mechanism would be similar to the proposed mechanism for drivers and would allow finer granularity (for example, RSA verification without RSA signature). Arm is considering standardizing the (as yet non-existent) JSON mechanism as a PSA specification. Best regards, -- Gilles Peskine Mbed TLS developer (and PSA crypto architect)

5 years, 6 months

1
0
0 0

How can I encrypt RSA private key with AES?

by Shariful Alam

Hi, I hope everyone is doing well. I am a beginner on mbedtls and cryptography. I hope you will understand if there is a lack of understanding or a rookie mistake from my part. So, My goal is to do a key-encryption key. I have an *RSA* private key file "*private.pem*" generated by OpenSSL. I want to encrypt the content of this "private.pem" with *AES* *encryption* and followed by *AES decryption *on the encrypted data. To do that, I read the "private.pem" file into a buffer and perform AES encryption. The problem is when I perform the AES decryption operation I get something else instead of the original "private.pem" data. I have a working example of AES encryption/decryption working on plaintext perfectly. So, I guess there is a flaw in my understanding of encryption/decryption of byte64 encoded string. Can someone please suggests me how can I encrypt RSA private key with AES? Thanks, Shariful

5 years, 6 months

1
0
0 0

[Mbed-tls-announce] Latest release link on github

by Janos Follath via Mbed-tls-announce

Mbed TLS version 2.24.0, 2.16.8 and 2.7.17 have been released recently. Version 2.7.17 is incorrectly marked as the latest release by github. Since this happens automatically based on the commit creation dates, this can’t be fixed until the next release. We have extended the release notes of 2.7.17 to warn about this and changed the download links on the website. We would like to confirm that version 2.24.0 is the latest release and the other two are the patch releases for the 2.16 and 2.7 long term support branches. My apologies for the inconvenience and thank you for your support! Best regards, Janos (On behalf of the Mbed TLS team) -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 6 months

1
0
0 0

[Mbed-tls-announce] Mbed TLS: Security Advisory and Release of Mbed TLS 2.24.0, 2.16.8 and 2.7.17

by Janos Follath via Mbed-tls-announce

Mbed TLS Security Advisories have been issued to accompany the release of Mbed TLS versions 2.24.0, 2.16.8 and 2.7.17, which have just been released. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.24.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.8, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.17) and in the 2020-07 security advisories (https://tls.mbed.org/tech-updates/security-advisories) We recommend all users to consider whether they are impacted, and to upgrade appropriately. -- Mbed-tls-announce mailing list Mbed-tls-announce(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls-announce

5 years, 6 months

1
0
0 0

Re: [mbed-tls] Print long MPI

by Gilles Peskine

Hello, 4096 bytes is a lot larger than a typical public key. 4096 *bits* is common for an RSA key. Are you sure you're using the correct units? By default the library doesn't support the creation of MPI that are larger than 1024 bytes. This is a configuration option (MBEDTLS_MPI_MAX_SIZE), although it's uncommon to change it (a larger value is hardly ever necessary, and a smaller value won't save memory except in RSA which needs at least 512 bytes for 4096-bit keys). However mbedtls_mpi_write_file itself doesn't have any size limit. Best regards, -- Gilles Peskine Mbed TLS developer On 27/08/2020 13:27, youssouf sokhona via mbed-tls wrote: > > Hello everyone, I think you are fine during this crisis. > > > > I am working now with mbedtls modulee, and I wanted to print a > function « mbedtls_mpi_write_file » to print the value of an MPI. This > function works with common values. > > > > However, when I want to print an MPI which is very long (about 4096 > bytes, a public key), it doesn’t work. Someone knows how to solve this > problem ? > > > > Thanks a lot > > > > Best regards, YS > > > >

5 years, 7 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls