Re: Parsing and generating CBOR certificates?
On Thursday, 21 January 2021 13:05:21 CET, David von Oheimb wrote: I'd welcome support for CBOR(-encoded) certificates since they can save a lot of space for both the data itself and the code handling it, which may be vital for IoT scenarios, for instance. It looks like the standardization of their definition got pretty far already. Although it is certainly possible to convert between DER-encoded ASN.1 (or at least its subset needed for X.509 certs) and CBOR, this is not strictly needed since there is a definition of natively signed CBOR certs. Thus all the ASN.1 fuzz, which is bulky and error-prone to implement and use, can be avoided then. https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress writes: The use of natively signed CBOR certificates removes the need for ASN.1 encoding, which is a rich source of security vulnerabilities. that's a huge and rather crucial difference as X.509 certificate signatures are specified over byte strings that are the DER encoding of the tbsCertificate structure you can send that certificate however you want, including by translating it into XML variant of ASN.1 but for verification you still need to turn that XML into DER so that you can verify that the signature that the CA created is correct if the signature is expected to be made over CBOR serialising of tbsCertificate, then that's a completely different certificate and it's the CA that needs to produce it, it's not something that openssl could do (convert from DER to CBOR) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
Re: OpenSSL 1.1.1g Windows build slow rsa tests
Hi Dan, On 21/01/21 19:22, Dan Heinz wrote: [...] Thank you all for the helpful suggestions. When I removed no-asm and built using nmake in the Developer Command Prompt for Visual Studio 2015, I ended up getting an error "VC-WIN64A X86 conflicts with target x64". From the command prompt I ran cl and saw this "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24215.1 for x86". So I was building for x86? I'm not sure why it built with no-asm, but it did. Once I ran the correct command prompt (I used Visual Studio x64 Native Tools Command Prompt), I saw a huge speed increase. For example, 2048 bits: Doing 2048 bits private rsa's for 10s: 8384 2048 bits private RSA's in 10.02s Doing 2048 bits public rsa's for 10s: 236090 2048 bits public RSA's in 9.98s Previously, I saw: Doing 2048 bits private rsa's for 10s: 409 2048 bits private RSA's in 10.00s Doing 2048 bits public rsa's for 10s: 15663 2048 bits public RSA's in 10.02s For further testing, I added back no-asm and my speed tests were in line with the downloaded openssl binary I was testing with. Doing 2048 bits private rsa's for 10s: 1868 2048 bits private RSA's in 10.00s Doing 2048 bits public rsa's for 10s: 71338 2048 bits public RSA's in 10.02s You can see removing no-asm does make a pretty large speed increase too. In summary, using the correct build tools helps (although I am surprised it built with no-asm). And removing no-asm sped things up. Not sure why you'd want to do a 'no-asm' build to begin with, but another thing worth testing with your "asm" build is to run the speed test like this: set OPENSSL_ia32cap=0 openssl speed rsa (Linux/UNIX: OPENSSL_ia32cap=0 openssl speed rsa) On my (10th gen Intel ) laptop this gives me a ~35% performance hit. Explanation: - no-asm build -> compiler generates all code, no hand-tuned assembly used at all; should be slowest - asm build + OPENSSL_ia32cap=0 -> no newer CPU features used, but hand-tuned assembly is used. Especially AES encryption takes a hit if you disable these newer features - asm build -> hand-tuned assemby, including the use of all new CPU features such as AES, SHA etc. I've found that this sometimes helps manage expectations when the "build environment" CPU and the "runtime environment" CPU are very different. I've seen a developer claim his/her code runs blazingly fast on his/her Core i7 bla bla but when deploying it on a cheaper runtime device performance is terrible. Note that no-asm + OPENSSL_ia32cap=0 should not have any effect compared to "no-asm". JM2CW, JJK / Jan Just Keijser
