EKON20 is now over, and there was a lot of people, great speakers, beautiful T-Shirt, and fresh beer! I've published the slides of my mORMot conferences on SlideShare... EKON20 From RAD to SOA with mORMot EKON20 mORMot Legacy Code Technical Debt Delphi Conference EKON20 Ride a mORMot EKON20 2016 […]
In order to follow best practice, our
.private key files are
always protected by a password. A random value with enough length and
entropy is always proposed by the
ECC tool when a key pair is
generated, and could be used directly.
It is always preferred to trust a computer to create true randomness (and
TAESPRNG was designed to be
the best possible seed, using hardware entropy if available), than using our
human brain, which could be defeated by dictionary-based password
Brute force cracking would be almost impossible, since
PBKDF2_HMAC_SHA256 Password-Based Key Derivation Function with
60,000 rounds is used, so rainbow tables (i.e. pre-computed passwords list)
will be inoperative, and each password trial would take more time than with a
regular Key Derivation Function.
The issue with strong passwords is that they are difficult to remember. If
you use not pure random passwords, but some easier to remember values with good
entropy, you may try some tools like https://xkpasswd.net/s which returns values like
But even then, you will be able to remember only a dozen of such passwords. In a typical public key infrastructure, you may create hundredths of keys, so remembering all passwords is no option for an average human being as (you and) me.
At the end, you end up with using a tool to store all your passwords (last
trend is to use an online service with browser integration), or - admit it -
store them in an
Excel document protected by a password. Most IT
people - and even security specialists - end with using such a mean of storage,
just because they need it.
The weaknesses of such solutions can be listed:
- How could we trust closed source software and third-party online services?
- Even open source like http://keepass.info/help/base/security.html may appear weak (no PBKDF, no AFSplit, managed C#, SHA as PRNG);
- The storage is as safe as the "master password" is safe;
- If the "master password" is compromised, all your passwords are published;
- You need to know the master password to add a new item to the store.
ECC tool is able to work in "cheat mode", storing all
.private key files generated passwords in an associated
.cheat local file, encrypted using a
As a result:
- Each key pair will have its own associated
.cheatfile, so you only unleash one key at a time;
.cheatfile content is meaningless without the
cheat.privatekey and its master password, so you can manage and store them together with your
- Only the
cheat.publickey is needed when creating a key pair, so you won't leak your master password, and even could generate keys in an automated way, on a distant server;
cheat.privatekey will be safely stored in a separated place, only needed when you need to recover a password;
- It uses strong File Encryption, with proven PBKDF, AFSplit, AES-PRNG, and ECDH/ECIES algorithms.
After weeks of implementation and testing, we introduce today a new feature of our mORMot Open-Source Framework.
Asymmetric encryption, also known as public-key cryptography, uses pairs of keys:
- Public keys that may be disseminated widely;
- Paired with private keys which are known only to the owner.
SynEcc unit features a full asymmetric encryption system, based on
cryptography (ECC), which may be used at application level (i.e. to
protect your application data, by signing or encrypting it), or at transmission
level (to enhance communication safety).
A full set of high-level features, including certificates and command line tool, offers a stand-alone but complete public-key infrastructure (PKI).
There are still a few days for "very early birds" offer for EKON 20 conference, and meet us for 3 sessions (including a half-day training/introduction to mORMot)! Join us the 7-9th of November in Düsseldorf! Our sessions are not restricted to mORMot, but will use mORMot to illustrate some […]
In any modern application, especially on
Client/Server nTier architecture as our little mORMot offers, we
often have to persist some private keys in a safe way.
Problem with such keys is that they consist in small amount of bytes (typically 16 or 32 bytes), easy to be left somewhere in disk or memory.
Given the abilities of recent forensic data recovery methods, data can't be destroyed on magnetic or flash storage media reliably.
We have just added to our SynCrypto OpenSource library
the Anti-forensic Information Splitter algorithm, as proposed in
TKS1, and implemented in the LUKS
LUKS is the de-facto standard of platform-independent standard on-disk format for use in various tools.
2016-04-22. Open Source
You should have noticed that Delphi 10.1 Berlin has been released. Our Open Source projects, including mORMot and SynPDF and their associated documentation have been updated to support this new revision. Any additional feedback is welcome, as usual!
Once your application is multi-threaded, concurrent data access should be
protected. We already wrote about how debugging multi-thread
applications may be hard.
Otherwise, a "race condition" issue may appear: for instance, if two threads modify a variable at the same time (e.g. decrease a counter), values may become incoherent and unsafe to use. Another symptom of broken logic is the "deadlock", by which the whole application appears to be blocked and unresponsive, when two threads have a wrong use of the lock, so are blocking each-others.
On a server system, which is expected to run 24/7 with no maintenance, such issues are to be avoided.
In Delphi, protection of a resource (which may be an object, or any
variable) is usually done via Critical
A critical section is an object used to make sure, that some part of the code is executed only by one thread at a time. A critical section needs to be created/initialized before it can be used and be released when it is not needed anymore. Then, some code is protected using Enter/Leave methods, which would lock its execution: in practice, only a single thread would own the critical section, so only a single thread would be able to execute this code section, and other threads would wait until the lock is released. For best performance, the protected sections should be as small as possible - otherwise the benefit of using threads may be voided, since any other thread would wait for the thread owning the critical section to release the lock.
We will now see that Delphi's
TCriticalSection may have
potential issues, and what our framework proposes to ease critical
section use in your applications.
We have seen previously how the ORM part of the framework is able to provide
Trail for change tracking.
It is a very convenient way of storing the change of state of the data.
On the other side, in any modern SOA solution, data is not at the center any
more, but services.
Sometimes, the data is not stored within your server, but in a third-party Service-Oriented Architecture (SOA).
Being able to monitor the service execution of the whole system becomes sooner or later mandatory.
Our framework allows to create an Audit Trail of any incoming or outgoing service operation, in a secure, efficient and automated way.
2015-11-21. Pascal Programming
There is a very trendy move, since a few years, to value so called "meta-programming".
In short, it is about the ability to treat programs as their data.
It is a very powerful paradigm in functional languages, and it was also introduced to OOP languages, even in SmallTalk a long time before this concept was trendy in Ruby, C# or Java.
In OOP compiled languages, reflection is used to achieve a similar behavior
at run-time, mainly via RTTI (Run-Time Type
Delphi supports RTTI since its version 1, as it was heavily used e.g. for all UI streaming.
In our framework, we rely on RTTI for its main features: ORM, SOA and MVC - and even in some other parts, like Desktop UI generation.
But RTTI could easily be abused.
Here are some thoughts, started as a comment in a good old Mason's blog article about how RTTI performance may be a bottleneck.
My comment was to get rid of RTTI, and follow a SOLID implementation with explicit OOP code, like use of
If you compare with existing client/server SOA solutions (in Delphi, Java,
C# or even in Go or other frameworks), mORMot's
callback mechanism sounds pretty unique and easy to work with.
Most Events Oriented solutions do use a set of dedicated
messages to propagate the events, with a centralized Message
Bus (like MSMQ or
JMS), or a
P2P/decentralized approach (see e.g. ZeroMQ or NanoMsg). In practice, you are expected to
class per message, the
class fields being
the message values. You would define e.g. one
class to notify a
successful process, and another
class to notify an error. SOA
services would eventually tend to be defined by a huge number of individual
classes, with the temptation of re-using existing classes in several
interface-based approach allows to gather all events:
- In a single
interfacetype per notification, i.e. probably per service operation;
- With one method per event;
- Using method parameters defining the event values.
Since asynchronous notifications are needed most of the time, method
parameters would be one-way, i.e. defined only
const - in such case, an evolved algorithm would
transparently gather those outgoing messages, to enhance scalability when
processing such asynchronous events. Blocking request may also be defined
var/out, as we will see below, inWorkflow
Behind the scene, the framework would still transmit raw messages over IP
sockets (currently over a
WebSockets connection), like other systems, but events notification would
benefit from using interfaces, on both server and client sides.
We will now see how...
2015-10-23. Pascal Programming
As we already notified in this blog, Embarcadero has been finally bought by IDERA. Delphi users received a letter from Randy Jacops, IDERA CEO. Written in my mother language, in perfect French. Nice! The letter states that they have 20,000 customers... It sounds more realistic than the numbers […]
Illustrated Spare Parts Catalog is, as its name suggests, a software for creating and publishing spare parts catalogs. It uses mORMot for client-server communication and ORM, and SynPdf for the reporting. Sounds like a powerful solution. It is also a testimony that you could use big databases (20 GB […]
In Delphi code, NULLable types do not exist as such. There is no
int? type, as in C#.
But at SQL and JSON levels, the NULL value does exist and should be converted as expected by the ORM.
In SQLite3 itself, NULL is handled as stated in http://www.sqlite.org/lang_expr.html
IS NOT operators).
It is worth noting that NULL handling is not consistent among all existing database engines, e.g. when you are comparing NULL with non NULL values... so we recommend using it with care in any database statements, or only with proper (unit) testing, when you switch from one database engine to another.
By default, in the mORMot ORM/SQL code, NULL will appear only in
case of a BLOB storage with a size of
Otherwise, you should not see it as a value, in most kinds of ORM properties.
Null-oriented value types have been implemented in our framework, since the object pascal language does not allow defining a nullable type (yet).
We choose to store those values as
variant, with a set of
TNullable dedicated types, as defined in
type TNullableInteger = type variant; TNullableBoolean = type variant; TNullableFloat = type variant; TNullableCurrency = type variant; TNullableDateTime = type variant; TNullableTimeLog = type variant; TNullableUTF8Text = type variant;
We just noticed a nice feedback from a mORMot user. Vojko Cendak commented the well-known DataSnap analysis based on Speed & Stability tests blog article written by Roberto some months years (!) ago. It is not meant to be the final word, perhaps there was some tuning possible for RTC (which is […]
2015-08-31. Pascal Programming
We expected Delphi XE9, and now we have Rad Studio 10 Seattle, with Delphi renamed as Delphi 10 Seattle, or simply DX. No big news for the Delphi compiler itself (we are still waiting for Linux server support), but a lot of FireMonkey updates, Windows 10 compatibility enhancements, enhancements to […]
You know certainly that our mORMot Open Source framework is an ORM,
i.e. mapping objects to a relational / SQL database (Object
You may have followed also that it is able to connect to a NoSQL database, like MongoDB, and that the objects are then mapped via an ODM (Object Document Mapping) - the original SQL SELECT are even translated on the fly to MongoDB queries.
But thanks to mORMot, it is not "SQL vs NoSQL" - but
"SQL and NoSQL".
You are not required to make an exclusive choice.
You can share best of both worlds, depending on your application needs.
In fact, the framework is able to add NoSQL features to a regular relational / SQL database, by storing JSON documents in TEXT columns.
In your end-user code, you just define a
variant field in
the ORM, and store a
TDocVariant document within.
We also added some dedicated functions at SQL level, so that SQLite3 could be used as embedded fast engine, and provide advanced WHERE clauses on this JSON content.
Among all its means of transmission, our mORMot framework
WebSockets, allowing bidirectional communications, and interface-based
callbacks for real time notification of SOA events.
After several months of use in production, we identified some needed changes for this just emerged feature.
today a breaking change of the data layout used for our proprietary
WebSockets binary protocol.
From our tests, it would increase the performance and decrease the resource consumption, especially in case of high number of messages.
An enthusiastic mORMot user, named willo in the forum, just started a blog about his experiments with our framework.
The information there is clear, simple, and right to the point.
If you are a little lost in our huge documentation, it is a good place to start!
A lot of our code, and probably yours, is highly relying on text process. In our mORMot framework, most of its features use JSON text, encoded as UTF-8. Profiling shows that a lot of time is spent computing the end of a text buffer, or comparing text content. You may know that In its SSE4.2 feature […]
One common problem when handling dates and times, is that time is shown and entered as local, whereas the computer should better use non-geographic information - especially on a Client-Server architecture, where both ends may not be on the same physical region.
A time zone is a region that observes a uniform standard time for
legal, commercial, and social purposes.
Time zones tend to follow the boundaries of countries and their subdivisions because it is convenient for areas in close commercial or other communication to keep the same time.
Most of the time zones on land are offset from Coordinated Universal Time (UTC) by a whole number of hours, or minutes.
Even worse, some countries use daylight saving time for part of the year, typically by changing clocks by an hour, twice every year.
The main rule is that any date and time stored should be stored in
UTC, or with an explicit Zone identifier (i.e. an explicit offset to
the UTC value).
Our framework expects this behavior: every date/time value stored and handled by the ORM, SOA, or any other part of it, is expected to be UTC-encoded.
At presentation layer (e.g. the User Interface), conversion to/from local times should take place, so that the end-user is provided with friendly clock-wall compatible timing.
As you may guess, handling time zones is a complex task, which should be
managed by the Operating System itself.
Since this cultural material is constantly involving, it is updated as part of the OS.
In practice, current local time could be converted from UTC from the current system-wide time zone. One of the only parameters you have to set when installing an Operating System is to pickup the keyboard layout... and the current time zone to be used. But in a client-server environment, you may have to manage several time zones on the server side: so you can't rely on this global setting.
One sad - but predictable - news is that there is no common way of encoding
time zone information.
Under Windows, the registry contains a list of time zones, and the associated time bias data. Most POSIX systems (including Linux and Mac OSX) do rely on the IANA database, also called
tzdata - you may
have noticed that this particular package is often updated with your
Both zone identifiers do not map, so our framework needed something to be shared on all systems.