user21203

78 reputation

bio	website
	location
	age
visits	member for	2 months
	seen	Mar 3 at 20:01
stats	profile views	2

	78 reputation	bio	website		visits	member for	2 months
5 badges		location			seen	Mar 3 at 20:01

summary answers questions tags badges favorites bounties reputation activity

31 Actions

suggestions reviews revisions comments badges posts accepts all

Mar 1	accepted	Can active attacks really decrypt a particular AES-256, CBC, PKCS#7 encrypted file?
Feb 28	comment	Can active attacks really decrypt a particular AES-256, CBC, PKCS#7 encrypted file? Do you think these concerns of active attacks against local CBC encrypted files are more theoretical than practical? Could you provide some information about the practicality of such attacks, how long time they could take, etc.? Would you urge everyone to dump CBC and switch ASAP to something like EAX?
Feb 28	revised	Can active attacks really decrypt a particular AES-256, CBC, PKCS#7 encrypted file? added 4 characters in body
Feb 28	accepted	How less secure is an encryption if we know something about the original data?
Feb 28	asked	Can active attacks really decrypt a particular AES-256, CBC, PKCS#7 encrypted file?
Feb 28	awarded	Commentator
Feb 28	comment	How less secure is an encryption if we know something about the original data? Another question I have is that if I use HMAC SHA-1 in PBKDF2 to generate the key <-- this HMAC is totally unrelated to the one you mention in the context of CBC,GCM,EAX?
Feb 28	comment	How less secure is an encryption if we know something about the original data? Can you elaborate on whether what you mention is just theoretical or has actually been successfully carried out in practice? For instance, if given an encryption program that encrypts files with AES-256, CBC mode, and a file encrypted with this program, are there active attacks against that file? (the cracker have access to the program that created the file of course). If this is the case, wouldn't this imply that AES-256 CBC is in fact a non-secure crackable algorithm that shouldn't be used anymore? Why do people use it?
Feb 28	comment	How less secure is an encryption if we know something about the original data? Aren't active attacks used against "streaming" data such as through an active network connection? How useful are active attacks against a given encrypted file (assuming still that we know the "abcdef" of the original)?
Feb 28	asked	How less secure is an encryption if we know something about the original data?
Feb 27	accepted	How does PKCS#7 padding work with AES-256, CBC mode?
Feb 27	comment	How does PKCS#7 padding work with AES-256, CBC mode? I still don't get how padding can be done before encryption, because often we are encrypting the whole data in small pieces at a time, until we hit the end. At the end there is usually a "finalize" function that is supposed to take care of the padding. So how did it happen before encryption? Can you please elaborate?
Feb 27	asked	How does PKCS#7 padding work with AES-256, CBC mode?
Feb 26	accepted	Key length and hash function in PBKDF2
Feb 26	asked	Key length and hash function in PBKDF2
Feb 26	accepted	Is it safe to have the salt equal to IV?
Feb 26	comment	Is it safe to have the salt equal to IV? Ok, thanks. Makes sense! Final question (i hope): So you agree that a 16 byte salt is a good size for the salt, or would you recommend a larger (or smaller) salt?
Feb 26	revised	Is it safe to have the salt equal to IV? edited body
Feb 26	comment	Is it safe to have the salt equal to IV? As I said (and as you know) I use a random generator (that generates random raw bytes) to generate a 16 byte salt. (1) Why do people "usually" use (multiple) iterations of PBKDF2 to generate both the key and IV? Why not just ask PBKDF2 to generate a 16 byte key only, and use the random generator again to generate the other 16 bytes for the IV? Is there any security difference there? (2) In this "usual" scenario that you mention, in my case of AES256, this would mean asking PBKDF2 to generate a 32 byte output, using the first 16 bytes for the key and the other 16 bytes for the IV, correct?
Feb 26	comment	Is it safe to have the salt equal to IV? So no, the salt is not consant. Why would it be? I generate different keys every time, storing the random salt in the encrypted file.