![]() |
![]() |
#1 | |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
![]() ![]() Quote:
I wrote most of the stuff in the readme.txt so will just add that here. Code:
modrobert @ 2015-02-21 This is an AES-256 ECB cipher file based encryption tool I developed in C for classic Amiga (68k), but the code is portable so it should compile on most sane operating systems. Full source code is included in the file archive. The benefit with this AES-256 implementation compared to others is that it doesn't allocate any large memory buffers to encrypt/decrypt, so you can handle large files with little memory and resources on the target system. When creating a key file for the cipher I recommend using as much of the 32 bytes (256 bits) you can, at least over 7 chars to make it harder to bruteforce. You can just type ASCII text in the key file, like a password, but for stronger cipher it is better with "binary bytes" to utilize all bits. I recommend the FileX hex editor on aminet if you want to hammer the hex codes straight into the file, its a great tool BTW. ;) Function: AES-256 ECB encrypt or decrypt a file. Feature : Encrypted block counter for increased entropy. Syntax : aes [option] <key file> <input file> <output file> Options : -e = encrypt, -d = decrypt. Result : 0 = ok, 1 = read error, 2 = write error, 3 = arg error. Note : Only the first 32 bytes of the keyfile will be read. Alternately, just type 'aes' in an Amiga shell where the file is for info on the command line usage. Included files: aes - 68k binary compiled with vbcc on real Amiga under WB 3.1. readme.txt - You are reading it now. :D source/aes.c - My file based command line tool to encrypt/decrypt a file. source/aes256.c - AES-256 routines modified to use sbox tables for speed. source/aes256.h - Header file structs and prototypes. source/demo.c - FIPS 197 compliance test written for the AES-256 routines. source/compile.txt - Command line to compile the source on Amiga with vbcc. Changelog: v1.20 - Added block numbering to encrypted file for increased cipher entropy. AES-256 buffer: [ <block number 4 bytes> <plaintext data 12 bytes> ] v1.01 - Fixed typo, this is ECB, not CBC, thanks Piru. v1.00 - Initial release. Background: The lightweight AES-256 C framework is developed by Ilya Levin and Hal Finney, and is well suited for the purpose. More information about the authors and license in the source code. This minimalistic implementation is impressive compared to most other stuff out there which usually involves bloated libraries, strange licenses, or just questionable functionality in general. There is demo code included you can compile to test that it meets the FIPS-197 requirements according to their advanced cryptographic standard. Have fun! ![]() EDIT: After checking some more; the block counter in plaintext for increased entropy can be regarded as a partially implemented CTR. Attached file SHA256 hash: 015aff195027efa79360d2cabf71b79b1f58655d41e27c1adadbbe94aa6c7fe3 Last edited by modrobert; 26 April 2021 at 15:35. Reason: Attached AES-256 v1.20. |
|
![]() |
![]() |
#2 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 13,843
|
Cool, I design the AES-256 in SED's (self encrypting drives). We use ECB and XTS we don't do CBC anymore
We also do SHA-256 for salting keys. Nice to see something new. |
![]() |
![]() |
#3 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 42
Posts: 9,532
|
Whenever you do modifications to crypto algos, you better know your stuff. I'll wait for some peer review.. ;-)
|
![]() |
![]() |
#4 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
I thought the disclaimer took care of that?
![]() |
![]() |
![]() |
#5 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 42
Posts: 9,532
|
I pointed Piru towards this, as he's done cryptanalysis quite often..
Code:
< Piru> now lesson to everyone thinking of creating their own cryptographic software < Piru> it's far too easy to mess up royally. better keep using the industry standard tools and methods < Piru> case study: http://eab.abime.net/showthread.php?t=77078 < Piru> I have a secret picture called secret.pnm. lets encrypt it < Piru> lets be generous and use totally random key! < Piru> openssl rand 32 > key < Piru> aes -e key secret.pnm encrypted.pnm < Piru> so we're secure now. right? < Piru> well except that: < Piru> echo -e "P6\n1280 687\n255" | dd conv=notrunc of=encrypted.pnm < Piru> pnmtopng < encrypted.pnm > you-failed-at-crypto.png < Piru> https://sintonen.fi/pics/you-failed-at-crypto.png < Piru> Problems: < Piru> - It's ECB not CBC. < Piru> - It's missing HMAC. < Piru> How to fix it: < Piru> - Use CBC mode with cryptographically strong random IV < Piru> - Add HMAC calculated over the IV + cipherdata < Piru> - At decrypt verify the HMAC before performing decrypt < Piru> ...or just use "openssl enc" like everyone else. < Piru> aaaand this concludes the cryptolesson. https://sintonen.fi/pics/you-failed-at-crypto.png |
![]() |
![]() |
#6 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
I've seen that repeating pattern weakness regarding images before, but not an actual solution to it, assumed it was one of the AES weaknesses.
Ask Piru if he has that image file in its original form, I want to test it with OpenSSL. EDIT: Never mind, found it here: https://vikingvpn.com/blogs/security...ments-with-aes EDIT2: Updated the info about this being AES-256 ECB, not CBC. Thanks Piru. I will make some changes and release an update shortly. OK, attachment in first post is now v1.01 where it states ECB instead of CBC. EDIT3: I confirmed OpenSSL sucked pretty bad regarding this AES-256 ECB weakness also. Code:
openssl enc -aes-256-ecb -in openssl_test.pnm -out openssl_aes256_ecb_test.pnm echo -e "P6\n640 400\n255" | dd conv=notrunc of=openssl_aes256_ecb_test.pnm pnmtopng < openssl_aes256_ecb_test.pnm > openssl_aes256_ecb_test.png http://www.eurasia.nu/images/submitted/openssl_test.png After AES-256 ECB encryption: http://www.eurasia.nu/images/submitt...6_ecb_test.png My mistake was that I misinterpreted the AES routines as CBC, when it actually was ECB. Will focus on trying to improve my tool now instead, got MD5 running pretty fast on Amiga, wondering if that is good enough for the HMAC. I suspect SHA is way too demanding (as in slow). Last edited by modrobert; 18 February 2015 at 02:59. |
![]() |
![]() |
#7 | |
Join Date: Jul 2008
Location: Sweden
Posts: 2,268
|
Pretty interesting to see those images and how they retain enough information to be able to clearly read the text.
Does it work equally well (or bad...) with other types of uncompressed data that can take a bit of wrangling, f.ex. integer WAV data? Quote:
http://aminet.net/package/util/cli/sha256 |
|
![]() |
![]() |
#8 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Leffmann,
I had a quick look at your SHA-256 routines, was really impressed, and written in assembler which is perfect for this project. Thanks a lot, will try your code soon, and feel free to change mine. Before reading your post I was thinking about coding the XOR block chain routines for CBC in assembler, which should be easy enough for me, hehe. Since the IV only needs to be randomized for the first block in CBC it doesn't matter if a bit slow, only matters if incredibly slow. I'm reading up on the "Blum-Blum-Shub" pseudo random generator at the moment. Regarding the images and AES-256 ECB, I'm a bit sceptic to how useful this weakness really is for an attacker (it looks impressive when trying to discredit methods though, hehe). I would be more worried to see actual fragments of plain text data appearing in the stream than broad formations which clearly is a result of the small 16 byte block size and repetition using the same key. However, imagine if chaining the data actually introduces other weaknesses. Sure, the image test looks all random static and people are happy, but you might have weakened the whole system by doing so. Last edited by modrobert; 18 February 2015 at 19:22. |
![]() |
![]() |
#9 | |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 42
Posts: 9,532
|
Hi,
Quote:
"Yes. Actually this it the only situation where MD5 can still be considered safe. For any other uses MD5 should be considered wholly insecure." |
|
![]() |
![]() |
#10 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Conclusion:
After checking some more, to add cryptographically strong randomization required by the IV for CBC will take this project pretty far from being lightweight, either depending on double precision math libraries, or other hardware/human device to generate the random IV data. The memory requirements would also increase, slower processing in general, not to mention CBC will introduce new weaknesses unless further algorithms are used to pad the cipher data, all leading to a level of bloat which makes it less suitable for classic Amiga hardware. Also, AES-256 CBC with HMAC seems more appropriate to use for client/server based communication where HMAC protects the integrity of the data, eg. to prevent "man in the middle" attacks (MITM). If you don't care about data integrity, and only want some level of obfuscation on a flat file, then there is no need for HMAC, or am I missing something? This tool currently provides aes-256-ecb, which seems to work as intended, I will leave it at that. If you want some form of file integrity and improved visual entropy in the encrypted data I recommend storing the unencrypted (plaintext) data in an lha or zip file and then encrypt the archived file. Last edited by modrobert; 21 February 2015 at 02:00. |
![]() |
![]() |
#11 | ||
Computer Nerd
![]() Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 46
Posts: 3,412
|
Quote:
Quote:
|
||
![]() |
![]() |
#12 | |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Quote:
This is how openssl does it in the header of "encrypted data" (ciphertext). Code:
00000000 53 61 6C 74 65 64 5F 5F B8 4F 35 94 87 EC 8A B7 Salted__.O5..... ![]() You can question using ECB for the purpose, but I have my doubts about using CBC as an alternative after reading about a weakness regarding XOR chaining all blocks, where sub sequent block plaintext bits can be derived from changing bits in the adjacent one without having the key by bruteforce decrypting the file. Sure, CBC gives you nice random looking entropy when viewing the file, but you have weakened the system by chaining it with XOR, and in effect created an unintended "Turing machine" of sorts to aid clever attackers. You can avoid the weakness if the "server" (program) is running in your control and has additional layers of session security by adding and verifying HMAC, but not when the whole flat file (ciphertext) is available to the attacker using a custom designed program completely in his/her control where the HMAC validation can be bypassed. Last edited by modrobert; 19 February 2015 at 02:34. |
|
![]() |
![]() |
#13 |
Computer Nerd
![]() Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 46
Posts: 3,412
|
To modrobert:
From what I understand is that a crypto algorithm gets a key as an input, generates a sequence of secure pseudo random numbers equal in length to the data you want to encrypt, and then XORs the sequence with the data. The security should rely entirely on the secureness of the pseudo random numbers generated. The stronger the sequence, the better the encryption. Perhaps this is the approach you should take. Side note: I'm not a crypto specialist ![]() Edit: After looking at the encrypted example image in more detail, I noticed repeating patterns. Look at the s characters in OpenSSL (magnify them). You'll see that they're identical pixel for pixel. This means that this encryption method is broken. Repeating data in a file should not be encrypted in the same way. If you have a text file with ten times 'foobar' in it, then each of the foobars should be different. Security through obfuscation is not security. Security comes from an algorithm being sound. It shouldn't matter one bit if people understand the code completely. Last edited by Thorham; 19 February 2015 at 02:18. |
![]() |
![]() |
#14 | ||||
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Quote:
Quote:
Quote:
Quote:
There are so many cipher weaknesses published out there, if you search around and actually read the released papers. The attackers are clearly ahead in the game. You will realize that almost nothing is secure unless you pay a lot of attention exactly how to implement and layer existing methods on case to case basis, and even then it is not completely secure, nothing really is. Last edited by modrobert; 19 February 2015 at 03:49. |
||||
![]() |
![]() |
#15 | ||
Computer Nerd
![]() Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 46
Posts: 3,412
|
Quote:
Quote:
Don't use AES in ECB mode. Pick a mode that's secure even if it's slow on 68k. What's more important, speed or security? Also, OpenSLL implements several algorithms. Both cyphers and hashes. Some of these are secure and some are not. An example would be SHA2 and MD5 hashes. SHA2 is still secure enough, while MD5 is completely broken. The insecure ones are probably only in OpenSLL for compatibility. Don't use them, use the secure ones. |
||
![]() |
![]() |
#16 | |||
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Quote:
As I mentioned several times previously, the feasible CBC method relying on XOR has a serious weakness. To quote myself from previous post: "You can question using ECB for the purpose, but I have my doubts about using CBC as an alternative after reading about a weakness regarding XOR chaining all blocks, where sub sequent block plaintext bits can be derived from changing bits in the adjacent one without having the key by bruteforce decrypting the file. Sure, CBC gives you nice random looking entropy when viewing the file, but you have weakened the system by chaining it with XOR, and in effect created an unintended 'Turing machine' of sorts to aid clever attackers. You can avoid the weakness if the "server" (program) is running in your control and has additional layers of session security by adding and verifying HMAC, but not when the whole flat file (ciphertext) is available to the attacker using a custom designed program completely in his/her control where the HMAC validation can be bypassed." Quote:
Quote:
My previous advice to encrypt an already compressed file archive like lha or zip instead of raw image data pretty much gives you the entropy and integrity provided by the flawed AES-256-CBC with "encrypt-then-HMAC", and the added bonus of making the encrypted file smaller. Last edited by modrobert; 19 February 2015 at 05:03. |
|||
![]() |
![]() |
#17 | |
Computer Nerd
![]() Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 46
Posts: 3,412
|
If you want to use AES, then you have to pick the right mode for the job. Here's an interesting post on StackOverflow:
http://stackoverflow.com/questions/1...cb-ctr-ocb-cfb You should also search for 'aes mode' in the cryptography section of StackExchange: http://crypto.stackexchange.com/ Quote:
Don't use ECB. ECB is not for encrypting multiple blocks. |
|
![]() |
![]() |
#18 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
I don't "have to" do anything, and no one "have to" use this against their own will, I already linked OpenSSL in my previous post, the world is full of choices. I have explained my motivations thoroughly. So, what's up with the broken record routine?
Play nice or I will design my own cryptographic method and post here, imagine the shit storm of posts that would produce with people who advice against it. ![]() Any random advice posted online should be taken as law, especially wikipedia, right? Without empirical tests, just tell everyone else the same thing like a parrot. Did you know I edit some of the wikipedia pages? Anyone can edit, and if a person appears to be correct the info is rarely removed or edited. Scary thought, you might actually be linking me my own advice. I was really eager to implement CBC on my own because it would mean writing the XOR routines in assembler and linking it with the rest, and was happy about leffmann's SHA256 for potential use to generate HMAC, but then I hit the first hurdle, to add a cryptographically strong random routine was harder than expected, and cost a lot of system resources to do right when thinking Amiga classic terms. Sure, you can just wing it and grab some custom chipset register bytes and hope for the best, but then it wouldn't really be CBC, would it? Then came the worst part, the weakness I mentioned before which at first seemed hard to accomplish, but later when going deeper into research material turned out to be pretty awful and requiring relatively few loops to gain a whole block of plaintext data so you can't really call it "brute force", more like "served on a platter", thank you CBC. If you search around almost every page hit will tell you to use CBC instead of ECB, and they will either show the Tux image appearing on ciphertext to quote wikipedia or some other picture to prove their point. No one seems to even bother mentioning that each block is still secure with ECB, as in not breached yet, even if the pattern appears. I'm aware there are attack possibilities with similarities on the blocks, but being aware of the weakness makes it less of a problem, and it is still a hell of a lot better than plaintext. I rather have block similarities with ECB, which is still functioning at the core, than tricking people into feeling safe with CBC just because half of internet thinks it is best. |
![]() |
![]() |
#19 | |
Computer Nerd
![]() Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 46
Posts: 3,412
|
To modrobert:
There are other AES modes than just ECB and CBC. This is why I said to use the right mode for the job. Both ECB and CBC have problems, but they're not your only choice. Here's a nice quote from http://tonyarcieri.com/all-the-crypt...robably-broken Quote:
As for generating randomness on Amiga hardware, probably not possible to be truly secure. For non-secure applications that simply need random seeds, I use a combination of hardware registers and SHA1 or SHA2 (to remove bias). For SHA2 I simply add the contents of eight hardware register bytes to each other, write the resulting byte to the SHA2 input buffer, and repeat this for all 64 bytes in the SHA2 input buffer. Then I hash the buffer. Great for getting entropy that's ten million times better than a time stamp. Whether or not it's secure is anyone's guess (but security wasn't the goal for this). |
|
![]() |
![]() |
#20 |
old bearded fool
![]() Join Date: Jan 2010
Location: Bangkok
Age: 55
Posts: 697
|
Thorham,
Thanks for the tips about random seed. In my opinion the attitude about cryptography should be; anything is better than plaintext. You could always experiment by adding daredevil command line option, eg. --this-shit-might-fail-badly, to make the user aware they are bleeding edge alpha testing. So, thinking along these lines, in order to stop the state-machine XOR back and forth attack on CBC, what do you think would be a way forward? I have an idea about keeping XOR in CBC, but instead of doing XOR on the plaintext data before encrypting, do it on a checksum/hash of the plaintext data block instead. Perhaps that could prevent the unintended state-machine revealing block data, all the attacker would get is hash bits then. Last edited by modrobert; 19 February 2015 at 17:30. |
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
windows tool to convert ipf to wwp / normal adf file | jotd | Coders. General | 12 | 08 May 2014 09:02 |
universe amiga 500 256 colors ! ? | turrican3 | Retrogaming General Discussion | 14 | 09 April 2014 21:35 |
How to change default tool for file types | AndyFC | project.ClassicWB | 2 | 13 February 2013 10:18 |
Classic OS System.zip file problems | FOL | project.ClassicWB | 2 | 21 July 2007 17:48 |
Pal Amiga is 256 | redblade | Retrogaming General Discussion | 9 | 05 April 2006 16:30 |
|
|