[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y ] [Home]
4chanarchives logo
Is it better to encrypt a entire file as a string. with AES 128bit
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.

You are currently reading a thread in /sci/ - Science & Math

Thread replies: 12
Thread images: 2
File: 1431148615503.gif (559 KB, 200x200) Image search: [Google]
1431148615503.gif
559 KB, 200x200
Is it better to encrypt a entire file as a string. with AES 128bit or to encrypt every line individually??
>>
AES is a block cipher, in the 128-bit case it only takes 16 bytes at a time. To encrypt more than 16 bytes, you might need a way of chaining the blocks together. You can choose not to do that, and equal input blocks will result in equal output blocks (ECB mode), which gives hints about the data . Look at https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation , look for the penguin in ECB mode, that's your problem. You can also decide to XOR each input block with the previous cipher block (CBC mode) before encrypting. You can also keep a counter and think of a number you're only going to use once, then encrypt the number and counter and XOR blocks of input data with the resulting 16 byte value (Counter mode).

ECB is weak and shit both when encrypting all of it or lines at a time.
CBC needs a way to initialize the first block, an initialization vector (IV). If you encrypt individual lines, take care that you're not using the same IV twice, or else you can do some analysis on that shit.
Counter mode needs a number used once (called a nonce). Never use that twice: you'll generate the same blocks (called the keystream) you XOR your data with, differential attacks become possible.

I'd encrypt the whole file in one go: you don't have the repeated key problems that CBC and counter mode give you.
>>
>>7640393
for encrypting I am doing the following

import java.security.Key;
import java.security.MessageDigest;
import java.util.Arrays;

import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;

public class EncryptDecrypt {

public String EnCrypt(String text, String key)
{
String r = "";
try
{
//Pad Key
byte[] keyB = (key).getBytes("UTF-8");
MessageDigest sha = MessageDigest.getInstance("SHA-1");
keyB = sha.digest(keyB);
keyB = Arrays.copyOf(keyB, 16); // use only first 128 bit

// Create key and cipher
Key aesKey = new SecretKeySpec(keyB, "AES");
Cipher cipher = Cipher.getInstance("AES");

// encrypt the text
cipher.init(Cipher.ENCRYPT_MODE, aesKey);
byte[] encrypted = cipher.doFinal(text.getBytes());

r = new String(encrypted);
}
catch(Exception e)
{
e.printStackTrace();
}
return r;
}
}
>>
>>7640406
*Note* Ill be feeding files into a single string, than encrypting the single string... I do not plan on doing huge files currently.. so this should work fine.
>>
>>7640410
>>7640406
According to http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#SimpleEncrEx , if you don't provide an operation mode in Cipher.getInstance, it probably defaults to ECB mode. If the file has repeating parts, these will show up in the encrypted output. Consider specifying the block (and padding) mode as well by calling Cipher.getInstance("AES/CTR/PKCS5Padding");
>>
>>7640505
Or of course "AES/CBC/PKCS5Padding" or some other mode. Also, I probably should have said "AES/CTR/NoPadding", counter mode is basically a stream cipher so it doesn't need padding.
>>
>>7640372
>encrypt every line individually

How to break it is trivial:
Look for repeated lines, such a like in text is likely to be just '\n'
Now xor that repeated encrypted line with '\n' and then xor that with every line
Congratulations you've just decrypted the whole file
QED
>>
>>7640406
>java

GET THE FUCK OUT

>>>/g/ayfags buttbuddies are that way
>>
>>7640663
hmmm, if that was true then every encrypted file in the world would be decipherable, every file as "\n" either way...
>>
File: images.jpg (9 KB, 241x209) Image search: [Google]
images.jpg
9 KB, 241x209
>>7640667

>its a proof of concept mate, also I am using AES and SHA1 "standards" so it does not matter what language I program this in its as secure as any other language.. without handling memory manually.
>>
>>7640663
lol I just watched the imitation game too
>>
>>7640663
AES is breakable with /n returns.. you do not understand encryption..
Thread replies: 12
Thread images: 2

banner
banner
[Boards: 3 / a / aco / adv / an / asp / b / biz / c / cgl / ck / cm / co / d / diy / e / fa / fit / g / gd / gif / h / hc / his / hm / hr / i / ic / int / jp / k / lgbt / lit / m / mlp / mu / n / news / o / out / p / po / pol / qa / r / r9k / s / s4s / sci / soc / sp / t / tg / toy / trash / trv / tv / u / v / vg / vp / vr / w / wg / wsg / wsr / x / y] [Home]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.
If a post contains personal/copyrighted/illegal content you can contact me at [email protected] with that post and thread number and it will be removed as soon as possible.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com, send takedown notices to them.
This is a 4chan archive - all of the content originated from them. If you need IP information for a Poster - you need to contact them. This website shows only archived content.