Hi Hanno/all,
I can understand your view that "more is not always good" in crypto. The
reasoning behind the offering can be found in the following whitepaper:
https://csrc.nist.gov/csrc/media/events/lightweight-cryptography-workshop-2015/documents/papers/session1-shors-paper.pdf
I will
On 01/08/2018 03:10 PM, William Bathurst wrote:
> Hi Hanno/all,
>
> I can understand your view that "more is not always good" in crypto.
> The reasoning behind the offering can be found in the following
> whitepaper:
>
>
On 01/ 8/18 04:46 PM, Misaki Miyashita wrote:
(switching the alias to openssl-dev@openssl.org)
I would like to suggest the following fix so that a valid certificate
at .x can be recognized during the cert validation even when
.0 is linking to a bad/expired certificate. This may not be the
I'm not terribly savvy regarding IoT, but I imagine that they do talk
to something bigger. A server end, perhaps? What do we expect to run
on that end? What happens, in that case, if SPECK makes its way into
the TLS cipher suites? Would it be interesting to have OpenSSL
interop with such
(switching the alias to openssl-dev@openssl.org)
I would like to suggest the following fix so that a valid certificate at
.x can be recognized during the cert validation even when .0
is linking to a bad/expired certificate. This may not be the most
elegant solution, but it is a minimal
I'm wondering if one of the more specialised embedded cryptographic toolkits
mightn't be a better option for your lightweight IoT TLS stack. There is a
wide choice available: CycloneSSL, ECT, Fusion, MatrixSSL, mbedTLS, NanoSSL,
SharkSSL, WolfSSL, uC/SSL and many others. All of them claim to
