Leaderboard

The irony about this is that to build a RAD application you are using components that are by design loosely coupled and more or less easily testable in isolation. The issue starts with non-UI-related code written directly into UI control event handlers and accessing global states such as these global form variables. If one would write their RAD application also in a component-driven architecture, things would be way easier - but slapping code into event handlers is quick at first and a nightmare to maintain later.

Some libraries are not part of GetIt for obscure reasons within Embarcadero decision makers, e.g. our https://github.com/synopse/mORMot2/blob/master/src/crypt/mormot.crypt.core.pas which is probably the fastest AES library able to be statically linked, OpenSource with full source code, and highly maintained, on Delphi (and FPC). And before using AES in your project, ensure you understand its basics: - it is very easy to make something weak, so you need to know a little about today's best practices. - don't reinvent the wheel: if you want to transmit data, use TLS; if you want to store passwords in a DB, don't use encryption but salted hashes which can't be reversed; see if using OS level disk encryption (like BitLocker) is not a better approach; etc... - don't use direct/naive AES in your project, named ECB because it is weak https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB) - consider AES-CTR (or AES-GCM which also makes authentication) for instance. - there is also a need for 16-bytes padding of the encoded output - here Pkcs7 seems the de-facto standard. - something tricky is to create the 128-bit or 256-bit key: you need to have a strong derivation function, like PBKDF2 from human input or at least HMAC-SHA256 if you already have a secret key. - consider also asymmetric encryption: if you can use ECDHE derivation using public keys in your project, this is the way to go - it is much safer to share two public keys between peers and derivate a secret, than sharing a symmetric key, which can be leaked. - a proper IV filling is also essential: a common practice it to generate it from random, and put it at the beginning of the encrypted stream, or even better get this IV from some bits of the ECDHE derivation function. - in practice, AES with 128-bit is enough security for an application - it has more security that RSA-2048 certificates which are still used almost everywhere in the Internet. Our units allows all this, and much more.

I've now added the code and demo (with documentation!) for what I have been using as a replacement, here.

I need to provide some documentation, but I have this: https://github.com/DelphiWorlds/Kastri/tree/master/Demos/macOSStatusBar Also be aware that I personally use another variation of this because I had trouble with "dynamic" items when associating them with FMX menu items - it became easier to just forget FMX menu items entirely, though there's a bit more code involved. I can share that code later.

You are searching with the "regular expressions" check box enabled, hence the message

I've actually wondered about this myself. Isn't the purpose of the unit test to test what happens if you get invalid parameters? So this test would be expected to fail because invalid parameters (string) were sent in to a function expecting floating point. However, I suppose it could be argued that a calling a function whose parameters require a floating point, would not even compile in Delphi if sending a string, so a unit test of this sort is pointless?

Good question ! The thing is AES is an algorithm, not a solution, and not all protection library, look at it as a brick in a wall, so encryption is defined and there is padding algorithm also a brick and should go in such wall when needed, libraries that use algorithm should and must provide padding algorithm or at least have one included and activated all the time. So when even you want to encrypt then pick a library that provide both, like mORMot2 it has all these bricks, and i think it have also a higher level implementation to provide both encryption and padding in one class, but that for Arnaud to answer. Now for salting as term in encryption, it is about obfuscating or mixing, so it is about changing the value by adding entropy, it doesn't matter at the beginning or at the end, may be it is just hash step after the fact with extended value, like hash the password then calculate the hash of that hash with the user name. As for IV mentioned by Arnaud, IV is crucial to be used right with cipher blocks, it is critical as the key itself, and the rule is you must not use the symmetric key twice for encryption unless IV is different or unique, so random is not necessary, and just a serial number will do, but again IV in AES (as example) is block and should be 16 bytes long, so i would use the index (or a unique identifier ) in the users/password database to then hash it into 16 byte long IV, then encrypt the user personal data there (or his cards...). One very important note, IV is not secret and it doesn't need to be, meaning it is absolutely safe to be public as the encrypted data, the key on other hand should not be leaked, but for IV you can ship the encrypted data with its IV without a problem. Because the rule is don't use the key twice, so we can instead of changing the key we change the IV and keep the key, this is usage is to prevent the very powerful deferential analysis attack, also comparison leak attack. Hope that clear things.

Hi, Not sure what is your question is, but from what Arnaud wrote and where did he mentioned the salting, i can expand on this, The only place he mentioned salting is storing password, and the right way to store password is not to store them to begin with but to store something unique like a hash form them, this will eliminate the possibility get the password in its readable form, also will protect against dictionary attacks, also to store the password it is better to salt it first meaning if you users had the same password like this great one "12345" then the hash will be different because they were salted by adding something to them like the their login name ! before hashing, this will render dictionary attacks useless, even for the administrator or who people who can access the DB, it is useless and leaking such DB will be useless too, in case users used their password in different online accounts or services. AES is symmetric block cipher, will operate only on block of bytes, 16 bytes to be exact, so if you are going to encrypt "Tommi" then you need to pass it within 16 byte block, here comes the question what to be filled with the rest of this 16 byte and how the decryption process will recognize it was "Tommi" and remove the extra bytes, because AES decryption is also works only on 16 bytes blocks, padding is the solution, pkcs7 is the best to solve this, just remember when using encryption to check the padding algorithms.

Depends on what you consider "safe". Most stuff on GetIt comes with full source code, so you compile it yourself and for stuff like encryption you do not need any design-time packages, just the code units. I have used (ex) TurboPower Lockbox for encryption in the past; the most recent version can be found on Github.