StreamSec Home  Forum Home 
 
Welcome, Guest.
Your IP: 216.73.216.215
2026-09-18 15:02:48 
 Public Support
 StreamSec Tools 4.1.3.359 released - one day after 4.1.3.358, and why
Bottom
 
Total posts: 1
 Author StreamSec Tools 4.1.3.359 released - one day after 4.1.3.358, and why
Henrick Wibell Hellström

2026-09-18 13:49:05
Registered user
Embarcadero has released Delphi 13.2, and its announcement puts the new Linux64 compiler up front. That compiler did us a favour on its first outing: built with it, StreamSec Tools showed a fault that no earlier toolchain had ever shown - a bug in the PKCS#8 key format code that had sat in the library, invisible, for years. 4.1.3.358 went out on September 17. 4.1.3.359 followed on September 18 to fix it. If you build for Linux64 with Delphi 13.2, 359 is the release you want; everyone else gets the same fix and loses nothing by taking it.

WHAT THE NEW COMPILER FOUND

- What you would have seen: a private key that would not store. SetPrivateKey returned False with the key, the format and the caller all correct. The most visible form was CMS signing and enveloping failing for every key type at once - RSA, EC, EdDSA, ML-DSA and composite alike - while the matching certificate operations went on working, because only the private-key path goes through PKCS#8.
- What it was: a private key information object asks its key and parameter fields which member of their CHOICE is selected, and uses the answer as an index into a table of object identifiers. A field that has selected nothing answers -1, and the lookup used that number unchecked - reading whatever lay in front of the table.
- Why nobody saw it: what lies in front of that table is decided by the compiler and the linker, not by the library. For years it was a string constant the runtime left alone, and the read was harmless. The new Linux64 compiler lays memory out differently, and the same read became an access violation - caught inside the key manager's format check, so nothing was reported where it arose.
- What it was NOT: not the key file, not the key format, not the passphrase, not a key-format unit missing from your uses clause. If certificate operations succeed for a key type whose private key will not store, it is this defect.
- The fix: the lookup answers "no object identifier" for a negative index, which is what the caller already expected. An index in range behaves exactly as before. No source change on your part.

ALSO IN 4.1.3.359

- A truncated or unrecognised elliptic curve point now decodes to nothing. For the uncompressed and the two hybrid encodings, an octet string that was too short decoded to a point object with no coordinates, and reading anything from it dereferenced nothing. A single 04 octet was enough. Well-formed points decode exactly as before.
- The embedded CCADB root set carries a verification date of 2026-09-18. The trust itself does not move: the 121 roots are still the set established 2026-08-11, re-fetched and found identical, all self-signed, CA:TRUE and unexpired.

WHAT 4.1.3.358 BROUGHT

Most of you will take both releases at once, so here is the larger one. Its notes are 64 entries in twelve subject blocks; these are the ones to know about.

New:
- CMS AuthEnvelopedData (RFC 5083) with AES-GCM, from the same TstMPEnvelopedData component: choose GCM as the content cipher and you get the authenticated envelope.
- HCTR2, length-preserving and tweakable wide-block encryption, for where there is no room for a nonce or a tag (stHCTR2, stPolyval).
- The RFC 9266 channel binding is reachable from the component TLS client - and so from the HTTPS, SMTP, POP3 and IMAP clients - and a REST session can be bound to one connection.
- An SMTP submission now says how far it got: a Stage property and TryMailFrom on the client, a delivery report and a Probe on the smarthost agent, and the age of the oldest queued message on the spool.
- A CMS signed attribute naming who a message was written to, a signature produced without the signer certificate, snip frames padded to a fixed size, a snip/TLS client that shares a TLS engine it is given, and two certificate extensions for KEM certificates.
- In the Delphi 13 package: TstRequestCertificateGenerator, which issues a certificate from a PKCS#10 request and takes nothing from the request unless a handler says so, and StreamSec.Pdf.Canvas, a page-composition surface for the PDF family.
- ML-KEM is up to ten times faster and uses AVX2 where the machine has it. Composite ML-KEM decapsulation is about twice as fast with a key that is used more than once.

Fixes worth reading before you upgrade:
- On Win64, fixed-time multiplication was wrong for an odd number of 32-bit words, so an RSA key of, for instance, 1088, 2112 or 3136 bits signed and decrypted wrongly. An RSA private key whose modulus is not a multiple of 64 bits could not sign or decrypt at all.
- Integer arithmetic: modular exponentiation with a negative or over-long base on Win32 and Win64, the remainder of some exact divisions, P-521 and P-224 under concurrent use, several carries, an index bound and pool reallocation.
- TLS 1.0-1.2 finite-field Diffie-Hellman: the peer's public value is now checked (0, 1 and p-1 refused), and leading zero octets of the shared secret are stripped - about one handshake in 256 with another implementation used to fail on Finished. DH1 key agreement validates the peer's element too.
- A TLS engine shared by many components: its notification list is changed under its lock, first use is set up once, and freeing an engine no longer sweeps the ASN.1 collector sixteen times - stopping a server holding many certificates could take minutes.
- Three memory defects that all surfaced as one access violation in a destructor: that shared notification list, an SMTP server releasing its delivery agent twice, and a base64 decode writing one byte past its buffer.
- Certificates: the chain filter and tolerated expiry, KEM certificates in the trusted store, and a delegated OCSP responder accepted without the extended key usage that authorizes it.
- A socket wait on Linux, macOS, iOS and Android with a descriptor of 1024 or more, an SSH client discarding channel data while it waited for a port-forwarding reply, three unbounded waits in the snip TLS transport, and HexToBytes on an odd number of digits.

Behaviour changes - these alter what existing code does with no source change, so read them first:
- REST clients sharing one TLS engine install the engine's trust once; the shared engine carries the first client's trust.
- The TLS 1.3 server's ticket store fixes a ticket's expiry and identity when it is stored.
- RSA key generation: a modulus of odd length is now made exactly - a 2047-bit key has primes of 1024 and 1023 bits - where the request used never to return. With ifkgNIST, a length FIPS 186 has no parameters for now raises eKeyGeneration; 2049 or 3073 bits used to return a key one bit short. An odd length with ifkgExportable raises as well.
- A Delphi Linux64 build that links ML-KEM needs one more object file, stMLKEMAvx2Func.o, beside stAESNIFunc.o.

Deprecated: anonymous key exchange (TLSOptions.SignatureAnon).

Changed: an encrypted PKCS#8 private key is derived with 131072 PBKDF2 iterations and an explicit HMAC-SHA256 prf; a Snif response no longer echoes the arguments the caller sent; Linux64 is supported from 10.3 Rio, and iOS and Android from 10.4 Sydney.

The complete notes are in the archive: CHANGES.txt covers 4.1.3.359, and CHANGES_4.1.3.358.txt beside it covers 4.1.3.358.

DOWNLOADS

- Licensed users: StreamSec_Tools_4.1.3.359.zip is in the download area here on the forum.
- Evaluation builds, DCU only, Win32 and Win64, for Delphi XE3 through Delphi 13, built from the 4.1.3.359 source: the StreamSec Tools 4.x download page.
- Software bill of materials, CycloneDX 1.6: StreamSec_Tools_4.1.3.359.cdx.json. It names the archive by its SHA-256, dfd3732a082135f2403e0afd6848a7ddb94602b49a7adb8748f69265cc8af150.

Questions and reports are welcome in this forum, as always.
Top

:: Written with and Powered by StreamSec Tools 4.1 ::
Copyright © 2000-2026 StreamSec Handelsbolag
Forum data layer and page templates derived from the RealThinClient SDK web-forum example, Copyright © 2004-2022 Teppi Technology (MIT)