Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I think I'm missing something fundamental about password based data encryption.
A tool that cracks password hash based login authentication knows it's found the correct password (or an alternate password that still matches the hash) when it successfully logs in. But how does a tool that cracks file or stream based encryption using a password as the source for a key know when it's successful? It seems to me that different attempted passwords would turn an encrypted source stream into a different set of destination bytes, with a particular password generating the 'correct' set of bytes. I don't understand how a cracking tool would recognize that it had the correct unencrypted set of bytes, stop trying and report 'Cracked!'.
Most of the time the plain text uses a known pattern. If it would be fully randomized then the attacker cannot distinguish between success and failure. It could be that a set of keys may be returned, of which only one is correct. That said, most plain text contains enough information (like a longer piece of English text) to distinguish a correct key from the wrong one.
Furthermore, the encryption mode may leak enough information to distinguish between the plain text and random text. Block cipher modes - such as ECB and CBC - in particular may use some kind of plain text padding. This padding is added before block encryption, and generally contains identifiable information. Take a look at the PKCS#5/7 padding mode for instance.
Note that encryption algorithms themselves are required to even withstand known plain text attacks, so finding the key should be impossible even if you already know what the decrypted text looks like. However, using passwords weakens the amount of valid keys for modern cryptographic ciphers, so the strength of the password is of utmost importance.
Related
I have a little background of cryptography so forgive me if this is a silly question. Is there a secure way to encrypt a text using AES that produces the same output with the same input?
Edit
What i want is to store emails in a external analytics provider using AES256 or HMAC 256 (this is a company requirement). But i need to be able to decipher them lately and to distinguish between same emails without deciphering them. I know i can do this with two entries, one with AES and another using HMAC. But can i do this with AES alone and still be secure?
Yes and no. There is a mode called ECB, "electronic code book", that will always produce the same output (cipher text) for a given input (plain text) block.
However, unless you only send each plain text block one time, ECB is not secure. At first, an adversary who intercepts an encrypted message won't be able to decipher it. But, just like old time code books, as they continue to monitor encrypted messages and combine that with knowledge of the context in which they were sent, they can eventually break much of your code.
Use of ECB is generally discouraged. For most messaging applications, an AEAD mode like GCM is recommended.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been reading up on file encryption lately, and In many places I've seen warnings that encrypted files are susceptible to decryption by people so inclined regardless of encryption algorithm strength.
However, I can't get my head around how someone would go about attempting to decrypt an encrypted file.
For example, lets say you've got an encrypted file and you'd like to know it's contents. You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. What do you do? (Assume for this example that the encryption algorithm is a symmetric-key algorithm such as AES-256, I.E. a file encrypted with key which requires said key to decrypt it).
Additionally, how would your approach change if you knew the encryption algorithm used? (Assume in this case that the encryption algorithm used is AES-256, with a random key + salt).
There's two ways to answer this question, in the literal sense of how a perfect crypto system is attacked, and how real world systems are attacked. One of the biggest problems you'll find as you begin to learn more about cryptography is that selecting algorithms is the easy part. It's how you manage those keys that becomes impossibly difficult.
The way in which you attack the basic primitives depends on the type of algorithm. In the case of data encrypted by symmetric ciphers like AES you use Brute force attacks. That is, you effectively try every key possible, until you find the right one. Unfortunately, barring changes in the laws of physics trying every possible 256-bit key can't be done. From Wikipedia: "A device that could check a billion billion (10^18) AES keys per second would in theory require about 3×10^51 years to exhaust the 256-bit key space"
The problem with your question about coming across a seemingly encrypted file, with no knowledge of the methods used, is that it's a bit of a hard problem known as a Distinguishing Attack. One of the requirements of all modern algorithms is that their output should be indistinguishable from random data. If I encrypt something under both AES and Twofish, and then give you some random data, absent any other information like headers, there's no way for you to tell them apart. That being said....
You asked how knowledge of the algorithm changes the approach. One assumption cryptographers usually make is that knowledge of the algorithm shouldn't affect security at all, it should all depend on the secret key. Usually whatever protocol you're working with will tell you the algorithm specifications. If this wasn't public, interoprobility would be a nightmare. Cipher Suites, for example, are sets of algorithms that protocols like SSL support. NIST FIPS and the NSA Suite B are algorithms that have been standardized by the Federal Government, that most everyone follows.
In practice though, most crypto-systems have much larger problems.
Bad random number generation: Cryptography requires very good, unpredictable random number generators. Bad random number generators can completely collapse security, as in the case of Netscape's SSL implementation. You also have examples like the Debian RNG bug, where a developer changed code to satisfy a memory leak warning, which ultimately led to Debian generating the same certificate keys for every system.
Timing Attacks: Certain operations take longer to execute on a computer than others. Sometimes, attackers can observe this latency and deduce secret values. This has been demonstrated by remotely recovering a server's private key over a local network.
Attacks against the host: One way to attack a cryptosystem is to attack the host. By cooling memory, its contents can be preserved and inspected in a machine you control.
Rubber hose cryptanalysis: Maybe one of the easiest attacks, you threaten the party with physical harm or incarceration unless they reveal the key. There has been a lot of interesting case law on whether or not courts can force you to reveal crypto keys.
AES256 is effectively unbreakable.
From http://www.wilderssecurity.com/showthread.php?t=212324:
I don't think there's any credible speculation that any agency can
break a properly implemented AES. There are no known cryptanalytic
attacks, and actually bruteforcing AES-256 is probably beyond human
capabilities within any of our lifetimes. Let's assume that 56 bit DES
can be bruteforced in 1 sec, which is a ridiculous assumption to begin
with. Then AES-256 would take 2^200 seconds, which is 5 x 10^52 years.
So, you can see that without any known weakness in AES, it would be a
total impossibility within any of our lifetimes, even with quantum
computing. Our sun will explode, approximately 5 billion years from
now, before we obtain enough computing power to bruteforce AES-256
without a known weakness. IF a weakness in AES is never found, there
is absolutely no reason to ever look for another cipher besides AES.
It will suffice for as long as humans occupy the planet.
With basic Brute force attack for example. You ask a software to try every single combination between 1 character to 15 character with a-z A-Z 0-9 and wait.
The software will start with 0 to 10... then 0a, 0b, 0c until it finds the password. Wikipedia will give you more detail.
I partially agree with Andrew and partially with Jeremy.
In the case, if encryption key is generated correctly (random generated or based on complex password, good key derivation function and random salt) then AES256 is effectively unbreakable (as Andrew said)
On other hand, if a key isn't correctly generated. As example, just straight hash of 4 digit's PIN password, brute force could be very efficient.
Regarding "You have no idea what the key used to encrypt the file is, nor the encryption algorithm used. "
In most case, encrypted files has a header or a footer which specify something (an application used to encrypt a file, encryption algorithm or something else).
You can try to figure out algorithm by padding (as example 3DES has padding and AES has different padding)
I'm building a simple trivia game that has "hangman" style clues (where letters are revealed as the player asks for hints). I don't want to flat out send the answer with the question any user with sufficient smarts could figure it out) - rather I'd like to encrypt answers on the server and decrypt them on the client. Security isn't of huge importance I just want to make the process harder then it's worth for players. I was wondering if anyone could recommend a strategy for doing this?
A simple approach, which might be sufficiently difficult for most users, would be to send the answer and encryption key to the web client (as hidden form fields), and use Javascript to decrypt it on the fly (inside the browser). A simple exclusive-or'ing of the answer string characters with the key string should be sufficient to "shroud" the answer without requiring large amounts of crypto processing on the client side. Using more than one key string might increase the difficulty of cracking it, too.
I'm assuming that you don't want to implement full commercial-grade crypto on the client side, and also assuming that you only want to hide the answers for a few minutes at most.
I'm creating custom registration forms for Forms Based Authentication for a SharePoint 2010 site, and storing passwords as 'Encrypted' in the aspnet_Membership database table.
My setting in web.config shows that the 'decryption' parameter is "AES". My boss is asking that I look to use AES256, as it's more secure, but I'm having trouble working out how to do this. I've been Googling and "stackoverflow-ing", but so far I've not been able to find that one post that either explains what I need to do, or where to look for good information.
My questions, I think, are:
is "AES256" a valid value for the "decryption" parameter of ?
if not, is simply generating a longer "decryptionkey" all that's required to make AES stonger? i.e. if I make my decryption key 64 characters long, would that constitute AES256?
if I'm totally off base with my current thinking, can anyone put me on track, or explain (or link to an explanation of) how to update my web.config to use AES256 rather than the default AES?
Just in case anyone wants to say "You should use Hashed".. been there, discussed that, decision made to use Encrypted. Just thought I'd get that out of the way :)
No, you can only use "AES" as the decryption parameter for the AES algorithm.
Yes, if you generate one that is 256 bits (64 bytes) long, you effectively have AES256. In reality, you could generate one that is 512 bits long, too. The longer this value is, the stronger the encryption.
No need. You seem to be understanding it.
Now, in .NET 4.0, they've enhanced this a bit, allowing SHA256 to be used for validation as well. See MSDN's documentation (archive.org snapshot) for details.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Any salt at all will obviously help when salting and hashing a user's password. Are there any best practices for how long the salt should be? I'll be storing the salt in my user table, so I would like the best tradeoff between storage size and security. Is a random 10 character salt enough? Or do I need something longer?
Most of these answers are a bit misguided and demonstrate a confusion between salts and cryptographic keys. The purpose of including salts is to modify the function used to hash each user's password so that each stored password hash will have to be attacked individually. The only security requirement is that they are unique per user, there is no benefit in them being unpredictable or difficult to guess.
Salts only need to be long enough so that each user's salt will be unique. Random 64-bit salts are very unlikely to ever repeat even with a billion registered users, so this should be fine. A singly repeated salt is a relatively minor security concern, it allows an attacker to search two accounts at once but in the aggregate won't speed up the search much on the whole database. Even 32-bit salts are acceptable for most purposes, it will in the worst case speed an attacker's search by about 58%. The cost of increasing salts beyond 64 bits isn't high but there is no security reason to do so.
There is some benefit to also using a site-wide salt on top of the per-user salt, this will prevent possible collisions with password hashes stored at other sites, and prevent the use of general-purpose rainbow tables, although even 32 bits of salt is enough to make rainbow tables an impractical attack.
Even simpler-and developers always overlook this-if you have unique user IDs or login names, those serve perfectly fine as a salt. If you do this, you should add a site-wide salt to ensure you don't overlap with users of another system who had the same bright idea.
Currently accepted standards for hashing passwords create a new 16 character long salt for every password and store the salt with the password hash.
Of course proper cryptographic care to create really random salt should be taken.
Edit: My below answer answers the question as asked, but the "real" answer is: just use bcrypt, scrypt, or Argon2. If you're asking questions like this, you're almost certainly using tools at too low a level.
Honestly, there's no defensible reason not to have the salt be the same exact length as the hashed password. If you're using SHA-256, then you have a 256-bit hash. There's no reason not to use a 256-bit salt.
More than 256 bits won't net you any improvement in security, mathematically. But going with a shorter salt may always end up with a situation where a rainbow table catches up to your salt length -- especially with shorter salts.
Wikipedia:
The SHA2-crypt and bcrypt methods—used in Linux, BSD Unixes, and
Solaris—have salts of 128 bits. These larger salt values make
precomputation attacks for almost any length of password infeasible
against these systems for the foreseeable future.
128-bit (16-byte) salt will be enough. You can represent it as a sequence of 128 / 4 = 32 hexadecimal digits.
One answer might be to use as size of salt the value that the hash you are going to use provides in term of security.
E.g. If you are going to use SHA-512 use 256 bit salt since the security provided by SHA-512 is 256 bit.