Hot answers tagged aes
7
Decoy for whom?
Security, and cryptography specifically, has a need for public scrutiny. It's been proven time and time again that hiding the nature of the protocol/algorithm/scheme doesn't provide any tangible security. Kerckhoffs' principle explains this: A cryptosystem should be secure even if everything about the system, except the key, is public ...
7
A block cipher is an invertible transformation that maps an $n$ bit block of bits to an $n$ bit block of bits, under the control of a key (and where $n=128$ in the case of AES)
Now, we most often need to do things other than mapping blocks of $n$ bits; how we do that is using the block cipher within a Mode of Operation. A mode of operation is just a way to ...
4
From a user's point of view, AES improves on DES and 3DES in at least two important aspects beyond speed and key length:
AES is a 128-bit block cipher, which makes it more secure for huge volume of data than a 64-bit block cipher is. For example, any 64-bit block cipher in CBC mode is vulnerable to a simple distinguisher attack: the adversary has a chance ...
4
That is quite impossible. Lets assume that such an encryption scheme would exist and assume that it always outputs ciphertexts of length $n$ bits.
Then, because the scheme is assumed to encrypt plaintexts of arbitrary length, it in particular encrypts all plaintexts of length $n+1$ to ciphertexts of length $n$.
However, there exist twice as many plaintexts ...
3
One of the factors that determines how hard it is to forge a MAC for a given message is how long the MAC is. If it's 1 bit long, you can definitely produce the correct MAC in two tries.
$2^n$ is the number of possible bit-strings of length $n$; $1/2^n$ is the probability that any random bit-string happens to be the MAC (of length $n$) for a given message ...
3
Yes, feasibility to guess the plain text size might be a serious vulnerability in real life scenarios. For instance, in traffic analysis the approximate length of the messages in a communication, might reveal enough information about what is communicated, for it to be possible to deduce the gist of it. If such threats exist in your case, however, you will ...
3
This seems like it may be an unnecessary complication. Why not encrypt the whole file at once, and HMAC the entire result? Or alternatively, use an encryption mode that has this built in, like AES-GCM?
But to answer your original question, no, it does not introduce any weaknesses. If it did, knowing the value to within 16 bytes wouldn't be much of a ...
3
16 bytes is 128 bits, which matches the block size of AES-256, but not "256 bit block" in the (original) title. Hence the question is ambiguous: was it meant 16, or 32 bytes?
For 16 bytes: ECB reduces to single-block encryption, and yes ECB is safe, for a definition of safe that let one test identity of plaintexts by testing identity of the ciphertexts.
...
3
If you know that the integer is fixed in size (always in the range 1-1000), then the second approach is fine. Effectively, you still have a random nonce (what you are calling the "junk"); you concatenate the nonce and the integer, then encrypt the result with AES-ECB. This works.
Do make sure that you choose a large enough random nonce. I recommend ...
3
When we say "RSA is broken" do we mean that a practical attack is discovered to retrieve the private key from the public, or do we mean that given a ciphertext and no knowledge of either the private or the public key the attacker can decrypt the data?
First off, we always assume the attacker has the public key. Someone saying "RSA is broken" could mean ...
3
Designing an HSM or other secure device is relatively easy; making it reliable even in the absence of adversary requires careful engineering; making it safe against adversaries with some level of physical access is hard; demonstrating that it is safe (for some definition of that) is even harder.
One thing to worry about is integrity of stored data ...
2
Step 1: good job, this is the right way. You can also use bcrypt or scrypt for extra resistance. Make sure you have chosen sufficiently strong parameters, that is, 64-bit salt and 10000 rounds absolute minimum.
Step 2: no! once you have a strong derived master key, you don't need to apply PBKDF2 on any keys derived from this master key. You are just wasting ...
2
From a users point of view, encryption algorithms tend to look alike. You feed the key and plaintext (and preferably a random initialization value) to the encryption function, and it produces the ciphertext.
See e.g. the example code for different algorithms from the pycrypto toolkit:
DES:
from Crypto.Cipher import DES3
from Crypto import Random
key = ...
2
Winzip allows enumeration of the file names contained within. Try WinRAR or 7zip instead. Winzip AES256 also uses CTR mode.
Both PGP and AES256-CTR are both currently considered "strong."
Can you provide more details about what exactly you're looking to do, or in what context you are evaluating safety and security?
2
The AES solution will fail if either:
the secret key is leaked, or
AES-256 is broken.
The RSA+AES solution will fail if either of the above happens, or if:
RSA-4096 is broken.
Thus, even without considering the relative likelihoods of these events occurring within the next 30 years, it is clear that the AES-only solution cannot be any less secure ...
2
I think what you are looking for is a Password-Based Key Derivation Function (PBKDF).
You can take a moderately strong password, like 12-14 random letters and numbers (no dictionary words though!), and throw it into the PBKDF function together with some other parameters, e.g. salt, number of iterations and the desired key length.
After that you have a ...
1
If you agree to define "fixed length cipher text" in such way that the import criterion isn't that the cipher text has a constant bounded length, but that the length of the cipher text is independent of the length of the plain text, the trick is simply to ensure that the cipher text is at least not shorter than the total amount of plain text.
In practice, ...
1
What you are looking for is a Pseudo Random Function that should be indistinguishable from uniform, even if the key material that is passed to it is not. One potential problem with your scheme is that the AES key schedule is not particularly good at extracting the entropy from keys that are not selected (pseudo-)randomly, such as passwords and pass-phrases. ...
1
Search for passwords on IT Security and you will find tons of advice on how to store passwords, and how not to. Your scheme is not a good method for hashing passwords: it is a fast hash, it lacks any salt, and it unnecessarily limits the password length. People have studied this at great length: before trying to re-invent the wheel, I suggest you read up ...
1
What sets apart government AES and a python script a highschooler can write is the implementation.
Even though AES is a completely open algorithm, the implementations used by the government are unclassified/controlled cryptographic items when not keyed - meaning even though the algorithm itself is not restricted in any way, the products that meet specific ...
1
Your question might be missing one plausible reason for governments to keep certain aspects of their cryptographic systems secret (besides the key), namely that their interest in learning the secrets of the opposition, might be as strong as their interest in keeping their own secrets to themselves. Hence, there are two questions that should be asked:
Would ...
1
I recommend you read a bit more about cryptographic design before getting into design of a HSM. Designing a HSM is basically designing a cryptographic protocol.
For instance, using AES-128-CBC is a bad idea, as it does not provide message authentication; instead, you should use authenticated encryption.
Similarly, rather than deriving a derived key in ...
1
Thinking a bit about your problem, you could potentially strengthen it by chaining key encryption algorithms. Using two-phase encryption (a symmetric algorithm like AES-256 protecting the data, and an asymmetric algorithm like RSA protecting the key) exposes you to weakness in either AES or RSA. You could attempt to strengthen the key protection by adding ...
1
If you assume AES is a pseudo-random permutation(which is pretty much necessary for it to be secure), then yes. However, it's way easier to just use a random IV/noce and keep the keys. Your new key must be distributed to both parties secretly, the IV/nonce can be public, so you can just send it (HMACed of course) in the clear. You obviously can't do this ...
Only top voted, non community-wiki answers of a minimum length are eligible
