StreamSec Home  Forum Home 
 
Welcome, Guest.
Your IP: 216.73.216.150
2026-09-27 12:23:08 
 Announcements
 StreamSec Tools 4.1.4.360 - every default is now the secure one, an SFTP path fix, private information retrieval and QR codes
Bottom
 
Total posts: 1
 Author StreamSec Tools 4.1.4.360 - every default is now the secure one, an SFTP path fix, private information retrieval and QR codes
Henrick Wibell Hellström

2026-09-27 10:10:26
Registered user
New release of StreamSec Tools, our Object Pascal crypto/TLS library for Delphi (XE3 and up, Win32/Win64, macOS, Android, iOS, Linux). The full changelog and the CycloneDX SBOM for this release are attached to this post.

UPGRADE IF YOU RUN THE SFTP SERVER

A junction or symbolic link inside the served folder led requests out of the root. Every request went through a lexical path check that never looked at the disk, so a link placed there - by anyone with local write access, or already present - let an SFTP user list directories and stat files outside the root, and remove, rename, create and truncate files there. Reading an existing file outside the root was refused, because that one path went through a verifying open. Releases 4.1.1.354 to 4.1.3.359 are affected. The path mapping now checks on disk as well.

If you cannot take a whole release, the source patch for older versions is in this section already.

EVERY DEFAULT THE LIBRARY CHOOSES FOR YOU IS NOW THE SECURE ONE

This is the first entry of the changelog and the one to read before upgrading.

TLS 1.2 drops finite-field DHE and DSA, and stops offering MD5, SHA-1 and SHA-224 as handshake signature hashes - RFC 10015 for the first, RFC 9155 for the last. A ServerKeyExchange or CertificateVerify signed over one of those is refused with illegal_parameter. The TLS, HTTPS and REST clients and the asynchronous server no longer preset CBC suites, DHE before ECDHE, or P-256; they take the options as they stand, which means the AEAD suites over ECDHE.

A PKCS#12 export now protects the private key AND the certificates with PBES2 - PBKDF2 over HMAC-SHA-256 at 131072 iterations, AES-256-CBC - where it used to fall back on 3DES and 40-bit RC2 at 2000 iterations. Certificates, CRLs, OCSP responses and CMS are signed with SHA-256, and verification refuses a signature made over MD2, MD5 or SHA-1 anywhere: certificates, CRLs, OCSP, PKCS#10, CMS signers and countersignatures, RFC 3161 tokens. A password-keyed TstCipher derives with PBKDF2-HMAC-SHA-256 instead of the old WeakPassword derivation.

Each of these is reversible where an old peer needs it, and the changelog says how.

One thing decides whether you notice any of it: a form keeps what it stores. A TLS component dropped on a form keeps every TLSOptions property the form saved - they have been streamed explicitly since 4.1.2.355 - as do DigestAlgorithm on the certificate generators and ContentDigestAlg on the CMS components. Open those forms and re-check them, or set the property in code. The key components' hash properties are the other way round and follow the new default. Anything created at run time starts from the new defaults.

TWO FIXES THAT COST PEOPLE REAL TIME

TstCertificateManager.ExportToPFXFile did not return when the chain reached a self-issued certificate the manager held: it stored the root again and again until memory ran out. That is every export whose chain reaches a root, and a self-signed certificate at once.

Reading a PFX, about one PBES2 key bag or safe contents in 255 refused the password it was written under - the first of the two candidate keys produced a wrong decrypt that happened to pass the padding check, so the second was never tried. Releases 4.0.1.337 to 4.1.3.359 are affected. An application writing fresh key files saw roughly 13 in 3000 come back "without a usable private key".

KEY STORES GOT SEVERAL TIMES FASTER

A key manager over a file store with PKCS8-Encrypted keys was running the password derivation eleven times to store one key and twenty-four times to open one message. Same iteration count, same bytes on disk, keys written by earlier releases read unchanged: storing a private key now takes about 0.5 s where it took 2 to 3 s, opening a message 0.7 to 0.8 s where it took 5 to 6.5 s. One application's test run went from 60-68 s to 10 s.

NEW: SINGLE-SERVER PRIVATE INFORMATION RETRIEVAL

A client reads one record out of a server's table without the server learning which record it read. The SimplePIR and DoublePIR schemes over learning-with-errors, with the scan kernel they rest on. The privacy is in the shape of the work, not in secrecy about it: the server's whole per-lookup computation is one matrix-vector product over every cell, so a query for record 7 and a query for record 70000 are the same instructions over the same octets.

Budget for the hint before anything else - it is megabytes where a query is kilobytes, and neither scheme is worth its cost unless a client makes many lookups against a table that changes rarely. The parameters are not the paper's: unstructured LWE at a secret dimension of 1280, measured against the lattice estimator rather than carried over from the paper, with the query-budget arithmetic written out. PIR.txt in the download has the whole story.

NEW: QR CODES, INCLUDING FROM A PHOTOGRAPH

Encoder, decoder and a detector that finds a symbol in a picture, to ISO/IEC 18004, versions 1 to 40 and all four error-correction levels. The detector takes a width, a height and one byte a pixel and knows nothing about TBitmap, FireMonkey or a camera; the two framework adapters are thirty lines each. The block and error-correction tables are verified against two unrelated encoders rather than proofread.

ALSO

HMAC takes its block from the hash's own rate, which changes the keys derived for SHA-512/224, SHA-512/256, SHA-3 and BLAKE2b, and PKCS#12 derives with the same figure. A key longer than the block, assigned to a hash's Key, is no longer rewritten in the caller's own object. The chain filter never admits a certificate whose signature does not hold, a stateful CheckSignature carries its codes until the new iSigned.ClearErrors, and the issuer lookup judges each candidate afresh.

FOUR CONSTRUCTIONS OF OUR OWN ARE DEPRECATED - the PCFB cipher modes, the keyed-IV ciphers, the WeakPassword key derivations and the SET3 cipher-stream container. Each still reads what it wrote; none should be chosen for new data, and the changelog names the replacement for each. ABC is [b]not[/b] deprecated.

NEW DOCUMENT: PRODUCTINFO.txt

Shipped in the archive and a topic in the help file. It is the information that accompanies the product, arranged as the items of Annex II of the Cyber Resilience Act: who made it, where to report a vulnerability, what it is for, and - the section to read if you read one - the defaults the library sets, the basis for each, and the decisions that stay with you.

It also states the support period for the first time: each release is supported for five years from its own publication date, and every security update issued in that window stays obtainable for at least ten years after it is issued. Reasoning on the CRA page, and the bill of materials on The Whole Iceberg.

Pages worth a look for what moved: TLS, Certificates, PKIX and CMS, SFTP, and Secure by design

Attachments:
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)