AES Encryption/Decryption Algorithm

[joedeshon]

This is good stuff, even if it is a little old. (Can't hide from a google search!)

Is this code available for 256-bit AES encryption? Or has anybody written 256-bit AES encryption for FreeBASIC? Or what would it take to change this code to 256-bit?

[csde_rats]

You are far better of using a proper cryptography library, like CryptoAPI/CNG (if you're on Windows) or cryptlib or even OpenSSL (whose APIs are often bad and poorly documented, but it's quite ok to use for primitives).

Also, if you have no training in cryptography I'd kindly suggest to use a library implementing a cryptographic protocol or file format or whatever you need, and not designing it yourself.

Edit: Over five years since my last post here. Only because of the email notification, though ;)

[tinram]

csde_rats is right.

I think Zamaster created this example as a prototype / proof-of-concept.

IMHO, I think what he coded in 2007 is excellent - as a concept.
Implementing an encryption cipher is not trivial, even when meticulously following the official specs.

However, this code example is dangerous.
(Believe this code has since 2007 been used in other people's projects, e.g. password storage program, on this forum.)

Before considering any increase in key size and number of rounds to 256-bit AES spec, this code, as per most cipher specs - is in ECB-mode.
Simply, that means for identical input, there is identical output. If you run the compiled code several times, the encrypted garbled string is identical every time - which can be rather helpful for attackers.

This would not be the case if CBC-mode were used - a different random initialization vector (IV) is used to set off the encryption of the data blocks.

Then there's padding to consider. And a crypto-secure random number generator for the IV. And passphrase hashing and stretching ... it goes on ... crypto is difficult to implement even if the cipher is correctly implemented (matching official test vectors).

Cryptlib may be the way to go if you can find sufficient examples.
Or for simple file encryption, you could do a call ( exec() ) from FB to GnuPG (GPG).
GPG has cross-platform executables and is a well-regarded encryption program.

[csde_rats]

AES is also notoriously hard to get right (without major side channels) in software. It's a cipher designed for hardware, after all. It's very likely that this implementation here is vulnerable to these kinds of attacks.

[Zamaster]

Hey! Guy who wrote the code here! It should be (heh) to AES spec as back when I wrote it (sheesh 9 years ago) I ran it on the AES test vectors and it was fully correct.

However you guys are right, do not use this for any serious encryption application. Why? As said previously, AES is pretty susceptible to side channel attacks and this code makes no attempt to secure itself from those. A timing attack is possible, though it would be tricky as the delays may be hidden by branch prediction in spots. The real issue here is that this implementation could suffer from a DPA (differential power analysis attack) were it on an embedded device as it also has little with which to guard itself (in fact nothing). As for softer hardware attacks (access violation), most of those should be prevented by a secure OS however a speculative "most of those" is not enough for this implementation to be called secure.

So my final recommendation, 9 years later, now with a Masters degree in computer engineering: I wouldn't trust any serious data to this implementation. It works to spec fine, but so little was done to safeguard it from side channel attacks that its hard to know where its actually safe to use. I think it should be fine to use on a local password storage program or for hashing, just don't go encrypting any top secret documents with it.

[Mihail_B]

I can recommand you guys a strategy to increase AES strength which is very good and has only one con. it increases traffic. But if security is what you really need, when encrypting insert in between any 2 chars a random char.

a = "MYSTRING"
l = lenght(a)
result = ""
for i = 0 to l-1
result = chr(random(256)) + chr(a)
next i

' PS: use a custom random function, prefer. not linear

This actually works with any cipher. It makes chain encryption (like CBC, GCM) much stronger.
If it would happen to have the same 8 chars string and same key/IV you will always get a different output after encryption which will totally make hard (or impossible) any brute force attack or analysis [...].

And my 1 penny for network related stuff : don't be affraid of using custom generated DiffieHellaman safe groups (DH) bigger than 2048 bits.
If you can cycle through many DH groups and pick a random one from a file for each new connection you will get strong protection.
And to generate "many" DH safe groups you could you in step1 [ssh-keygen -G moduli.candidates -b 2048] and in step 2 [ssh-keygen -T moduli.result -f moduli.candidates] (to screen DH groups; about 512 safe groups / per hour / per cpu thread @ 3ghz)

Hope this helps someone :)

[csde_rats]

This actually works with any cipher. It makes chain encryption (like CBC, GCM) much stronger.
If it would happen to have the same 8 chars string and same key/IV you will always get a different output after encryption which will totally make hard (or impossible) any brute force attack or analysis [...].

Never re-use the same Key/IV combination with any mode unless it's specifically meant to be fully nonce-reuse resistant (no widely used mode is, apart from KW modes unsuitable for general purpose use).

Reusing the same key/IV usually results in complete destruction of confidentiality (ie. attacker can read the plaintext); CTR, GCM, OCB, ... modes exhibit this, for example. In authenticated modes this can enable an attacker to forge signatures (GCM for example).

In other words, the security of these systems depends completely on the same key/IV combination being unique, never to be used for two not bit-for-bit equal messages.

If you can't guarantee that no IV reuse happens, use a random IV instead and ensure that not enough data for birthday statistics is encrypted under the same key (GCM, OCB have a 96 bit nonce, so you want to encrypt considerably less than 2^48 messages under the same key).

[Mihail_B]

Never re-use the same Key/IV combination with any mode unless it's specifically meant to be fully nonce-reuse resistant (no widely used mode is, apart from KW modes unsuitable for general purpose use).

I ment if it WOULD HAPPEN (due to unfortunate circumstances) to have same KEY/IV.

But if your text is "STRING" and you insert random chars in between any to chars you get "[r]S[r]T[r]R[r]I[r]N[r]G" it will always give you a new
encrypted text - even in unfortunate circumstances :)

If you have a https server and you share a file with a client, if someone is peeking at the network traffic he could deduce which file you sent by the size of the transfer.
eg:
the client gets https://www.facebook.com/facebook.png and then there's a delay between the next request.
facebook.png is a public resource, everyone knows it's size.

you start you https connection using a key obtained from DHE or ECDHE but an attacker could deduce with resources are transmitted and eventually because he knows the "plain text" it can perform an analysis on the whole connection.

But if you insert random chars in between each bytes of any file you will baffle (circumvent) attacker's analysis. He will be able to know which public file you receive but he will not helped by this in an attack against JSONs that contain [your] private information.

Key renegociation is rare in browsers due to the fact that browsers are optimized for speed and renegociations seem to take up some computation power. Anyway If you have a different connection for private data it will be better. But you can strengthen furthe more by using the algorithm i said ... insert random chars in between each chars of plain text (and take them out after decription).

Of course one should never use same KEY/IV, but as i told you, i have observed (in the past, dunno if things are corrected now) that browsers use even some temporary random key again and again and never bother to recompute it unless you start a new tab/window.
(it can be mittigated at server side in part by using options like : SSL_CTX_set_options(sslContext, SSL_OP_SINGLE_DH_USE); )

--
Ahoy !