EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Moving Encrypt example to AES

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#18014
Posted: 10/27/2011 12:23:13
by Vikas Patial (Basic support level)
Joined: 10/27/2011
Posts: 1

I was running the Encrypt Example and the demo works fine. But the implementation is that of a simple XOR encryption.So every byte is encrypted.

I would like to ask how do we go ahead with implementing something like AES , with 16 byte block size in the EncryptBuffer() function.

As AES Will produce 16 byte block even for a 1 byte encryption. I need advice on how to handle the AES block sizes with Encrypt and Decrypt.
#18015
Posted: 10/28/2011 03:24:11
by Vladimir Cherniga (EldoS Corp.)

Forwarded to the corresponding ticket.
#19541
Posted: 03/21/2012 05:43:19
by Jason Coleman (Basic support level)
Joined: 03/21/2012
Posts: 17

Hi There,

just started using this toolkit. Very nice design. I too am curious about using another form of encryption. Specifically AES, where the encrypted file has more information than the original.

The XOR is easy as the underlying file size does not change. How can we add more information to the encrypted file and still decrypt the normal data on-the-fly?

Keep up the good work. This is great.
#19542
Posted: 03/21/2012 07:37:24
by Eugene Mayevski (EldoS Corp.)

Using block ciphers for encryption is very non-trivial.

First of all, secure cipher modes are chaining, which means that seeking is not trivial as well. You would need to encrypt blocks of 16-64 Kb, decrypt them on access and cache decrypted block in memory.

Next, as you pointed, the size of the data will change (will grow up to be the multiple of the cipher block size). CallbackFilter lets you report file size different from the real one using OnEnumerateDirectoryC, OnPostGetFileSizesC, OnSetAllocationSizeC and OnSetEndOfFileC callbacks. However you need to get that "real" file size somewhere. We don't have ready recipes about how to implement this right.

RC4 algorithm (which is basically a XOR with a good key generator) is reliable when used properly (i.e. having a *good* key generator and take other safety measures related to RC4).

In general, encryption is handy on filesystem level. For example, we have AES encryption built into SolFS virtual file system or you can add encryption to Callback File System more easily than to CallbackFilter. Both SolFS and Callback File System create a separate file system though.


Sincerely yours
Eugene Mayevski
#19543
Posted: 03/21/2012 07:42:30
by Eugene Mayevski (EldoS Corp.)

My colleagues pointed that AES in CTR mode doesn't change data size, so you can try employing it.

We have implementation of CTR mode in our SecureBlackbox product, so if you use .NET or VCL API of CallbackFilter, you can also use .NET or VCL edition of SecureBlackbox to get AES encryption in CTR mode. If you have questions regarding Secureblackbox, please post them to the corresponding forum.


Sincerely yours
Eugene Mayevski
#19544
Posted: 03/21/2012 08:07:08
by Jason Coleman (Basic support level)
Joined: 03/21/2012
Posts: 17

Thanks Eugene,

the proposed mode you mention for AES turns a block cipher into a stream cipher. I understand the use of block ciphers for HDD encryption. I can't remember off the top of my head but is AES-CTR mode acceptable? I know that CTR mode is acceptable providing the key is not re-used (or salted if reused) and if some counter vs. a bit flipping attack are implemented (e.g. hash, keyed hash or dig signature). However, including the hash will change the size of the file.

How about Galois/Counter Mode (as per suite B encryption)? I think this is a CTR mode with a HMAC. So, again, the overall file size will change slightly.

However, my need is quite specific. I have an encrypted file (AES-128-CBC). The header of the file is in plaintext and contains the IV (initialisation vector) plus some extra data (file attributes, times etc.). The remainder of the file is the actual encrypted file.

What is want to do is as follows:

1. Decrypt the file (on-the-fly) according to some local conditions.
2. Use the header to aid in that decryption. For example, the IV is essential.

Is this possible without writing a HDD encryption tool? I don't want to decrypt every file on-the-fly. Just every file with a specific header.

Thank you for your time.
#19545
Posted: 03/21/2012 08:13:28
by Eugene Mayevski (EldoS Corp.)

You are welcome to discuss cryptography-related questions in SecureBlackbox forum.

As for your task - you need to buffer decrypted data in memory somehow: with CBC you can't implement random access without decrypting the complete file to memory (at least up to the place where reading occurs). If you expect only sequential access to data, then you should have no problems.


Sincerely yours
Eugene Mayevski
#19547
Posted: 03/21/2012 08:39:40
by Jason Coleman (Basic support level)
Joined: 03/21/2012
Posts: 17

So, the short answer is that it is not possible to do what I want with just the CallbackFilter product.

Thanks again Eugene.

J
#19548
Posted: 03/21/2012 09:40:00
by Eugene Mayevski (EldoS Corp.)

Why not possible? It's just not effective.


Sincerely yours
Eugene Mayevski
#19727
Posted: 04/10/2012 05:26:07
by Jason Coleman (Basic support level)
Joined: 03/21/2012
Posts: 17

True, it is not effective if using a block cipher. I've developed a c#-based AES-CTR solution that works.

Thanks for the help.
Also by EldoS: SecureBlackbox
200+ components and classes for digital security, signing, encryption and secure networking.

Reply

Statistics

Topic viewed 4103 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!