Encryption (AES)

[new_x 1]

Hi all, I planned to use AES encryption in a project. I searched and found that there are some packages available as third party available via GetIt. (No native support in Delphi for encryption/decryption). I returned to Delphi after several years (The last version I used was D7). My question is "Is every package listed in GetIt safe to use", the second question is "is there any package that you suggest" thank you in advance.

[Lajos Juhász 239]

 

[new_x 1]

Thank you Lajos, by the way for the second part of my question ("are all the codes/packages listed in GetIt safe to use") do you have any idea?

 

Regards

[PeterBelow 218]

2 hours ago, new_x said:

Thank you Lajos, by the way for the second part of my question ("are all the codes/packages listed in GetIt safe to use") do you have any idea?

 

Regards

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.

[new_x 1]

Hi Peter, 

 

That is very nice to contact a person from Team-B, regards, and thank you for your comment.

[Arnaud Bouchez 380]

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.

Edited December 18, 2023 by Arnaud Bouchez

[Tommi Prami 123]

13 minutes ago, Arnaud Bouchez said:

- there is also a need for 16-bytes padding of the encoded output - here Pkcs7 seems the de-facto standard.

What do you mean here actually. Add "salt" to the data to be crypted or to the crypted it result data?

 

and why is 16 bytes important, or it is 16 bytes or more, or any multiple of n bytes?

Edited December 18, 2023 by Tommi Prami

[Kas Ob. 91]

Hi,

20 minutes ago, Tommi Prami said:

What do you mean here actually. Add "salt" to the data to be crypted or to the crypted it result data?

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.

 

27 minutes ago, Tommi Prami said:

and why is 16 bytes important, or it is 16 bytes or more, or any multiple of n bytes?

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.

[Tommi Prami 123]

13 minutes ago, Kas Ob. said:

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, 

Used word Salt as to ask in different words. But your explanation, I think answered question. It is not about adding "salt" to beginning but padding to end.

I would think that is the job for the AES library, not for individual programmer using the library.  Kind would hope that best practices would be used as default, and if need something else, lets say receive data from 3rd party system, then you can change behavior.

 

-Tee-

[Kas Ob. 91]

12 minutes ago, Tommi Prami said:

I would think that is the job for the AES library, not for individual programmer using the library.  Kind would hope that best practices would be used as default, and if need something else, lets say receive data from 3rd party system, then you can change behavior.

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.

[Arnaud Bouchez 380]

On 12/18/2023 at 9:11 AM, Tommi Prami said:

What do you mean here actually. Add "salt" to the data to be crypted or to the crypted it result data?

 

and why is 16 bytes important, or it is 16 bytes or more, or any multiple of n bytes?

This is nothing about salting.

@Kas Ob. wrote it fvery nicely: this is because the AES encoding algorithm is a block algorithm by itself: it works on blocks of 16 bytes as input and output. It works only on full blocks, i.e. encoded output is always a multiple of 16 bytes.

So you need a way of "cutting" the result without leaking any information.

This is known as "padding" the output - PKCS#7 defined the most common way: you output up to 16 more bytes, in which you fill the remaining bytes of your data with the length of your data modulo 16. So once decrypted, you can "cut" back the result into the original size. For some chaining modes (like AES-CTR) there are some other ways of padding with no additional output bytes, but it is less common.

 

My point was: do not reinvent the wheel, or you are likely to obtain a weak safety.

[FaFaFooey 5]

Argon2 is the standard for storing a password hash now https://en.wikipedia.org/wiki/Argon2

[Arnaud Bouchez 380]

@FaFaFooey
Argon2 is nice for sure - but really complex, and difficult to implement.

So I am not sure it is "the standard of storing a password hash" on Delphi, in which I was not able to easily find a full-features library.

 

I like very much the https://en.wikipedia.org/wiki/Proof_of_work concept:

  Proof-of-Work Puzzle: the nonce is used as the puzzle for a Proof-of-Work challenge which the client has to solve (as part of anti-brute force protection). A simple scheme can be to send a nonce and ask the client to find a string that, when appended to your nonce, will have a SHA-256 hash beginning or ending with a certain number of zeroes (adjusting the number of zeroes allows adjusting the puzzle difficulty). When getting a puzzle response, check first the nonce validity, then the hash.

See https://www.delphitools.info/2016/01/07/nonces-and-tokens for the diverse means of authenticating an user.

 

 

 

 

[PeaShooter_OMO 10]

10 hours ago, Arnaud Bouchez said:

Argon2 is nice for sure - but really complex, and difficult to implement.

Why is it difficult to implement? Or shall I rather say; what about it makes it difficult to implement?

Edited January 3 by PeaShooter_OMO

[Tommi Prami 123]

31 minutes ago, PeaShooter_OMO said:

Why is it difficult to implement? Or shall I rather say; what about it makes it difficult to implement?

There is couple implementations. like: https://github.com/JackTrapper/argon2-for-delphi

Have not tested them tough...

 

-Tee-

[Brandon Staggs 185]

8 hours ago, Tommi Prami said:

There is couple implementations. like: https://github.com/JackTrapper/argon2-for-delphi

Have not tested them tough...

 

-Tee-

The comments on that readme explicitly state it's not complete. However, it also says Argon2 is not fully documented and isn't as good as bcrypt, both of which are really odd things to say.

[Arnaud Bouchez 380]

10 hours ago, PeaShooter_OMO said:

Why is it difficult to implement? Or shall I rather say; what about it makes it difficult to implement?

You may try to implement it properly, with all the appropriate testing coverage, and I guess you will find out.

There are name/value parsing, execution timing, and multiple parameters involved.

Existing implementations in Delphi are not widely used nor maintained. Not what we could call a "standard".

[Tommi Prami 123]

14 hours ago, Brandon Staggs said:

The comments on that readme explicitly state it's not complete. However, it also says Argon2 is not fully documented and isn't as good as bcrypt, both of which are really odd things to say.

I take it as the BCrypt is better if run it one second or shoter period. . Whats actually the point of Argon2 that you run it long, and use much resources, to make it hard for brute force attack, even with GPU farms.

[Brandon Staggs 185]

10 hours ago, Tommi Prami said:

I take it as the BCrypt is better if run it one second or shoter period. . Whats actually the point of Argon2 that you run it long, and use much resources, to make it hard for brute force attack, even with GPU farms.

Right, the whole reason for Argon2/id is for consuming a resources to generate a password hash so that a brute-force attack or rainbow table generation is not feasible. Calling Argon2 less secure than bcrypt because someone might use insufficient settings (that nobody would suggest using) is not reasonable. In fairness, the comments on that readme are pretty old. 

 

Anyway, I took this way off the rails, I just want to be sure someone who looks at that Delphi Argon2 project on github understands it is incomplete and its readme contains some very outmoded (at best) sentiments. :-)