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

Is it better to encrypt a entire file as a string. with AES 128bit

This is a blue board which means that it's for everybody (Safe For Work content only). If you see any adult content, please report it.

Thread replies: 12
Thread images: 2

File: 1431148615503.gif (559KB, 200x200px) Image search: [Google]
1431148615503.gif
559KB, 200x200px
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 (9KB, 241x209px) Image search: [Google]
images.jpg
9KB, 241x209px
>>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 posts: 12
Thread images: 2


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

I'm aware that Imgur.com will stop allowing adult images since 15th of May. I'm taking actions to backup as much data as possible.
Read more on this topic here - https://archived.moe/talk/thread/1694/


If you need a post removed click on it's [Report] button and follow the instruction.
DMCA Content Takedown via dmca.com
All images are hosted on imgur.com.
If you like this website please support us by donating with Bitcoins at 16mKtbZiwW52BLkibtCr8jUg2KVUMTxVQ5
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.
This is a 4chan archive - all of the content originated from that site.
This means that RandomArchive shows their content, archived.
If you need information for a Poster - contact them.