You are not logged in.
This is the forum thread discussion for https://blog.synopse.info/?post/2021/02 … ementation
Last week, I committed new ASM implementation of our AES-PRNG, AES-CTR and AES-GCM for mORMot 2.
They handle eight 128-bit at once in an interleaved fashion, as permitted by the CTR chaining mode. The aes-ni opcodes (aesenc aesenclast) are used for AES process, and the GMAC of the AES-GCM mode is computed using the pclmulqdq opcode.
Resulting performance is amazing: on my simple Core i3, I reach 2.6 GB/s for aes-128-ctr, and 1.5 GB/s for aes-128-gcm for instance - the first being actually faster than OpenSSL!
Online
amazing as always ab!
Offline
Great job. So awesome that mORMot 2 comes to us
Nicely structured, with new features.
Next logical step is to work on OpenSSL integration of the TLS layer
ab, what exactly this mean?
Will the socket based web server support HTTPS mode? (use key and certificate).
Last edited by George (2021-02-13 16:13:54)
Offline
@George
Yes, the socket web server would support TLS/HTTPS via OpenSSL, and also the client side - with no need of libcurl for basic HTTPS process.
I guess the best option for production would still be to have a nginx server locally as reverse proxy, to manage the incoming connections and the HTTPS - it is just great to use e.g. with Let's Encrypt, and if you use unix sockets on the loopback, performance is awesome. And nginx will always be more secure than mORMot as output server (its code is more audited for instance against DOS attacks).
But for a simple stand-alone HTTPS server, our mORMot server could be good enough.
What we would like to is add TLS support for Websockets. And add a thread pool for the WebSockets server connection - with mORMot 1.18, there is one thread per websocket client connected, so we will eventually use a thread pool also for the WebSockets server.
Online
Websockets makes much more sense with a thread pool.
Last edited by Leslie7 (2021-02-14 00:32:50)
Offline
hello,
really great result,
can I ask, do you support Argon2?
I'm referring, to start an instance E2E using SGX or TrustZone in random protected ram (isolated from OS) or remote net pipe, and extending using 32bit key with Argon2 hash. The most reliable until now.
A bientot!
(nowadays nothing than <> Argon2 has any value)
Do you will plan to implement X3DH, Double Ratchet, Curve25519 other than AES-256 e HMAC-SHA256?
Last edited by RObyDP (2021-02-15 10:37:42)
Offline
We don't have BCrypt, Scrypt or Argon2 implementations yet.
We have PBKDF2 Key Derivation functions, which are meant to be fast, especially on server side.
The idea is that we don't put all trust into the password cracking abilities - the main problem is IMHO between the keyboard and the chair in terms of user-entered password.
Online