AES256 command line utility (win32) which does not add a header

[peter-h]

There is a lot of these around but all seem to add a header. For example aescrypt.exe adds a load of stuff to the front, starting with "AES"

I am looking for a bidirectional utility, password on the command line in hex, which just encrypts say 512 bytes into 512 bytes.

There are plenty of AES C sources so I can have a go at freelancer.com, if nobody here can think of something.

[mariush]

Maybe this helps : https://odan.github.io/2017/08/10/aes-256-encryption-and-decryption-in-php-and-csharp.html

or use crypto-js : https://npmjs.com/package/crypto-js

example of using crypto-js at the bottom of this page:  https://velocitybytes.com/aes-encryption-and-decryption-in-java-and-javascript

[peter-h]

Thank you... yes indeed I came across some, but for a command line utility I am looking for a standalone win32 .exe, or, if I am going to give $50 to somebody (usually in Ukraine) to knock one up, C or C++ source.

Right now I am implementing https://github.com/kokke/tiny-AES-c/blob/master/aes.c on my target, and will test it against the test vectors, and if it works I can get a .exe done.

I was going to use the 32F417 hardware AES function but I don't actually need the speed, and doing so would preclude one day using a F407 (which doesn't have hardware crypto) or one of the chinese 407 knockoffs. ST do a lib which uses the hardware AES but it is so convoluted it would take me hours just to extract the bit I want

Incidentally are there win32 JS or PHP compilers which produce a standalone .exe?

[mariush]

No, can't make a standalone exe from php,  but you can run php scripts from command line ex php.exe script.php   and you can pick command line arguments / parameters by parsing the $argv array to get your input file, output file, whatever

Go / Golang is also quite easy to learn and the positive about it is that it builds static executables ... Here's a minimal example of AES-256 encryption and decryption : https://gist.github.com/yingray/57fdc3264b1927ef0f984b533d63abab

[oPossum]

Thank you... yes indeed I came across some, but for a command line utility I am looking for a standalone win32 .exe, or, if I am going to give $50 to somebody (usually in Ukraine) to knock one up, C or C++ source.

Right now I am implementing https://github.com/kokke/tiny-AES-c/blob/master/aes.c on my target, and will test it against the test vectors, and if it works I can get a .exe done.

Here is a self contained (no DLLs required) Windows command line program that does AES256 CTR using the C code you have specified.

Usage: AES256 infile outfile key

key is 64 hexadecimal characters

Encrypt and decrypt are symmetrical for CTR, so specifying the mode is not required.

I can modify to your spec and provide source code for approximately "Ukraine pricing".

[oPossum]

Update with support for ECB, CBC and CTR modes. Key length of 128, 192 or 256.

Usage: AESnnn mode key infile outfile

mode: ECBE, ECBD, CBCE, CBCD, or CTR

[peter-h]

Wow - amazing! Thank you.

Unfortunately, my AV software detected a virus in the zipfile and deleted it as soon as I downloaded it.

I had already given it to (yes...) a Ukrainian on freelancer.com who has written various utils for me before. The spec was

AES256.EXE

Requirements:

Normal win32 command line executable, standalone, no dependencies.
Runs in a win7-32, win7-64 (or higher) command line box.

C/C++ preferred. Needs to be possible to build a linux version later so no strange Microsoft dependencies.

aes256.exe e|d keyfile inputfile outputfile

All 4 parms mandatory.

e = encrypt
d = decrypt
Not case sensitive.

keyfile is the key and the file must be 32 bytes in size.

All 3 files are binary data.

Speed not important.

C source for aes256 provided. Note that the selection of aes256 (not aes192 or aes128) is already done in the .h file.
Same for CBC mode. Not ECB or CTR.

Test code provided - does 64 byte blocks. Final program needs to be tested with the data shown.

AES256 does 16 byte blocks, and uses a 32 byte key.

If input file size is not a multiple of 16 bytes, append 0x00 bytes until it is.
Output file size will be same as input file size.

If 'd' mode in use, input file MUST be a multiple of 16 bytes in size.

Clear error messages for each invalid parameter please.

I got it running on my target too, as an RTOS task. It does 512 bytes in 5ms which is amazingly slow. OK for the intended purpose, but pretty slow for use for TLS session encryption. The 32F417 hardware method is thus very desirable.

EDIT: your 2nd PDF does not show a virus. I guess it was a spurious detection. Are all your files pure binary i.e. keyfile = 32 bytes? I also wonder what is the correct IV. It seems to be 0x00 0x01 0x02...

[golden_labels]

CAREFUL! Unless you really know what you are doing, can provide a key from a CSPRNG (the exact key fed directly to AES, not a passphrase or KDF!) and have a secure way of conveying that key to the recipient: this is almost surely not what you want to do. Chances that more than one of these conditions are met are very low.

The issue is that you need a means to determine initialization vector.⁽¹⁾ It must be stored explicitly or may be derived from a password. However, for password-based keys you must have salt or the password would be vulnerable to dictionary attacks. So you end up with the requirement to store the IV or the salt.

If you want to try, see the enc command in OpenSSL (home). But I implore you: do not ever deploy that to production or, worse, release as a product to other people without first consulting a person with sufficient crypto expertise.

Code: [Select]

openssl enc -aes256 -pbkdf2 -iter 1 -nosalt -pass file:KEYFILE -in INFILE -out OUTFILEWhere INFILE is the input file, OUTFILE is the output file, KEYFILE is a file with CSPRNG-generated value (at least 32 octets).⁽²⁾ To decrypt:

Code: [Select]

openssl enc -d -aes256 -pbkdf2 -iter 1 -nosalt -pass file:KEYFILE -in INFILE -out OUTFILE
Obtaining OpenSSL on Windows may be a bit of a trouble, as the upstream is not offering binaries. As far as I can tell, cURL (home) offers the command in its Windows relase. If not, see if MSYS2 can’t provide it. If not, MinGW may be used to build it, or perhaps accessible over WSL.

The initial warning applies to any other software as well.

⁽¹⁾ Or a nonce in modes like CTR, CCM or GCM. The distinction is irrelevant in this post.
⁽²⁾ That is not the key yet — it will still be fed to a KDF, but in this case with no implications for security.

[oPossum]

aes256.exe e|d keyfile inputfile outputfile

All 4 parms mandatory.

e = encrypt
d = decrypt
Not case sensitive.

keyfile is the key and the file must be 32 bytes in size.

Updated per spec.

IV is all 0

[oPossum]

Are all your files pure binary i.e. keyfile = 32 bytes? I also wonder what is the correct IV. It seems to be 0x00 0x01 0x02...

The first 2 posted take the key on the command line. IV is all 0.

[peter-h]

Virus detected in last zip.

Yes I am aware of the weaknesses. I've been involved to some extent in crypto for about 30 years. Used to make some DES line encryptor boxes for, apparently, banking... Z180, 14MHz, 38k baud full duplex. Did an ASIC for another crypto product.

In this application, the IV is fixed (the value used for the standard test vectors seems to be 0 1 2 3 ... 0x0f, so why not use that?) and the key is ... the key. The key is also fixed. It will be used to encrypt a firmware file which is then decrypted on the target. As you will all point out, the key must be stored on the target and is thus vulnerable. But not that vulnerable, if the CPU has security fuses blown. The only really good solution for this is to use a smartcard chip which does the decryption on-chip, and I am not doing that because the application doesn't warrant it. So it is really just to block casual disassembly of a firmware update file, because they are bound to fall into the wrong hands, and of course that file (if it is updating the entire CPU FLASH) will contain any keys. I am using CBC over large blocks.

A dictionary attack on the 32 byte key will not be possible.

One interesting lesson from this exercise is how slow TLS (HTTPS) must be if the session crypto is done in software. I know one can trade speed for size (and even 25 years ago people were doing DES at 1mbyte/sec on an 80x86 at 50MHz, by using megabyte-sized precomputed lookup tables) but that AES code doesn't look too bad to me, and it is still doing 1 byte in 50us, which is unsurprising for the amount of code, but would slow down ETH data rate to below 100kbyte/sec which, admittedly, almost nobody would notice on an "IOT box" doing HTTPS to a private server But using the 32F417 hardware crypto is worthwhile in case something faster is needed one day.

The TLS setup (EC or RSA) takes a couple of seconds - long time even on a 168MHz 32F4. This is OK however.

FWIW attached is the MbedTLS aes.c, and an ST-supplied version using the 32F417 hardware. Both too bloated for me to follow easily.

[oPossum]

Changed some build settings to eliminate false positive by AV.

[peter-h]

Still detecting a virus...

Is there a problem with using an easy to guess IV? A google search is silent on specifics - just the usual clickbait copied from one website to another.

Digging around, it looks like most people are generating (for CBC) the IV and the key in one go, using whatever method they use for the key.

[oPossum]

Encrypted zip file

password: paranoidav

https://www.virustotal.com/gui/file/96647138ba06f53a3d80af10be406b0d97f9e0b1ae8c3502e4c5232d84334b83?nocache=1

[golden_labels]

Why do you even bother?

Most encryption schemes do not provide authentication, so you do not protect your device against malicious code. The cost of such an attack is greater, but that’s not the same meaning of word “protection” as used in cryptography. What you achieve is primarily separating the users from knowledge of what the device is doing.

Even worse: in the scenario you described the key is hardcoded. That means users can’t upload their own firmware, you losing the key prevents updates, and there is no mechanism to address encryption key leaks.

[peter-h]

There is a CRC (with a nonstandard initialiser) also, to prevent malicious code upload. Obviously there are more complicated ways of doing that too...

I am not describing the full reasoning behind this

opossum - your file comes up positive on some online scanners e.g.



https://www.virustotal.com/gui/home/upload

Someone said to me that any code containing aes256 flags up as a virus. EDIT: It is MS VC whose runtimes are triggering this.

[peter-h]

This job got a bit more complicated when I realised that the CBC mode must be done over 512 byte blocks only, not over the whole file which is what everybody else does. This is because I program the CPU FLASH from top down, doing the final boot block last (and doing it in one go - the 32k boot block takes about 300ms, so that is the sole "bricking window").

Anyway I have someone trying to knock this together now.

Thank you all for your suggestions.

Yes indeed if the key is lost then you can't upgrade the firmware, except with a debugger, which you can't do if you have set the security fuses to "max" But if you have set the security fuses to "max" you cannot upgrade the firmware anyway. There is no free lunch. What this scheme does give you is protection from disassembly of firmware distributed openly, which is actually really important because you never know who you are dealing with remotely. Whenever you bring out a new product, the first sales will be to competitors (in disguise of course). And even if somebody has got his hands on the physical product he still has quite a bit of hassle even if you didn't use any security fuses. And if you block SWD debugging then he has even more hassle. If the product has a huge value then the chinese will try to rip it off, and will succeed unless you have some sort of tamperproof key storage, which is more money...

FWIW I had a look at the aes256 code which comes with MbedTLS and while it is pretty opaque (to me) it uses much bigger tables, so I would expect it to be a lot faster than the 5ms=512 bytes of the tiny aes code I am using.

[gmb42]

Obtaining OpenSSL on Windows may be a bit of a trouble, as the upstream is not offering binaries

OpenSSL for Windows is easily installable via chocolatey (https://community.chocolatey.org/packages/openssl) and winget (https://winget.run/pkg/ShiningLight/OpenSSL) and probably other package managers as well.

[golden_labels]

I though that the assumption, that software should be obtained from trusted sources, is implicit and obvious.

Yes, of course anyone can just search for “openssl windows installer” and find some link. 

[gmb42]

I though that the assumption, that software should be obtained from trusted sources, is implicit and obvious.

Yes, of course anyone can just search for “openssl windows installer” and find some link. 

I'm missing something here.

Your initial issue was about the lack of pre-built binaries for Windows

Obtaining OpenSSL on Windows may be a bit of a trouble, as the upstream is not offering binaries

which is a bit odd as the upstream source (OpenSSL themselves) doesn't offer any pre-built binaries at all for any platform.

Obviously then, users that don't build OpenSSL themselves have to rely on the various distributions (and I include Windows here) to produce a "safe" package to install.

Why do you think the Windows packages of OpenSSL (personally I've only ever used those from ShiningLight) installed via a trusted package manager would be less secure than an OpenSSL package for [random OS] installed from [random distribution] via their trusted package manager?

[golden_labels]

Obviously then, users that don't build OpenSSL themselves have to rely on the various distributions (and I include Windows here) to produce a "safe" package to install.

Windows can’t be included, as Windows is not an entity. It’s a product. The entity is Microsoft, and they are not providing OpenSSL.

Why do you think the Windows packages of OpenSSL (personally I've only ever used those from ShiningLight) installed via a trusted package manager would be less secure than an OpenSSL package for [random OS] installed from [random distribution] via their trusted package manager?

How does a package manager being trusted has, by itself, anything to do with trust in the packages it can install? Considering that those are random files provided by anonymous persons, even less trustworthy than e.g. cesspool like AUR?⁽¹⁾

Are you aware, that you linked a binary that’s EOL’d, has over half hundred known vulnerabilities (including RCE), and can’t even deal with some commonly encountered situations a program may encounter in 2020s?

⁽¹⁾ I know AUR does not provide packages, but close enough for the argument. There are custom repos that build and publish pre-built packages from it (e.g. Chaotic).

[JPortici]

There are plenty of AES C sources so I can have a go at freelancer.com, if nobody here can think of something.

I needed to add some encryption of a file, just not to make it plaintext and i said, what the heck let's just use AES i'm sure to find something.
I don't know if you do Qt but it is just a few lines of code (get the stream from a QFile(path), call the oneliner to QAESEncryption, write the stream to the output QFile, using this library https://github.com/bricke/Qt-AES