Tag Info

New answers tagged

0

We know this is theoretically possible, but your search space is 2^126 right now and no sign of this improving. Good luck building enough supercomputer (all the computers on the planet combined aren't even close right now).


2

No, that's not really possible without blatant flaws of the implementation. Modern modes of operation of ciphers are resistent to attacks even if you know many pairs of plaintext and ciphertext - and the IV is public knowledge. Knowing it is the normal case. You also didn't mention what operation mode was used. Well, of course you could brute force the key, ...


2

Welcome to crypto SE. I guess, you are referring to the mix columns operation from the point of view with polynomials over $GF(2^8)$. A detailed explanation of this can be found at Wikipedia. It is a quite unusual structure, but it behaves just like you would consider any $GF$. The columns are first considered as polynomial, or better: as coefficients ...


0

First I find the question legitime and trying to evaluate the complexity is not a easy problem. But to the question how it's look like, I would mention beforehand that AES or any other crypto algorithm could be write in many others different ways. See for example https://www.iacr.org/archive/asiacrypt2002/25010159/25010159.ps BTW any crypto function ...


7

Both an AES-128 key (as defined by FIPS 197), and a TDES Keying Option 2 key (as defined by FIPS SP-800-67) are 128-bit bitstrings. Similarly, both an AES-192 key and a TDES Keying Option 1 key are 192-bit bitstrings. The differences are: In AES, all bits of a key matter to the result; in TDES, 1 bit out of 8 (the lower-order bit of each byte in ...


2

There are some differences between the keys of AES and 3DES. However I do think that your colleagues are more interested in the security of the primitive itself. The AES block cipher is rather more secure than triple DES. If a 128 bit triple DES key is created the amount of effective key bits - the bits actually used in the protocol - is 112 bits. This is ...


0

The key itself is really just a bitstring for (nearly?) all block ciphers. You can use the same key for different algorithms, but the cipher may need keys of different lengths. For example, AES can use keys with 128, 192 and 256 bit. 3DES is slightly more complex. It can use 2 keys or 3 keys with each 56 bit. 1 key would also be possible, but is not really ...


2

None of Twofish, Serpent and AES are currently known as broken, so as far as security is concerned, you can use any of them. AES has a slight advantage because it's very widely used, so if it gets broken you're more likely to hear about it and get relevant software updates quickly. The Snowden postings haven't changed much as far as cryptography usage is ...


1

Initialization Key hash function hashstring Configuration: E is Rijndael with a block size and key size of 256 bits Input: keystring Output: hash The keystring is padded up with bytes valued zero and split up in blocks of 256 bits $S_0$ to $S_n$; The key blocks $K_0$ to $K_n$ are generated, where $K_0$ consist of $S_0$. The following blocks - if any, ...


1

If you are constrained by the embedded environment, you should consider CCM instead of GCM as AES mode. One of the major constrain when implementing GCM is that the authentication part (the GHASH) is totally unrelated to AES and should be implemented in its own way. And, to make it reasonably fast, you have to use key-depended look up tables which will ...


1

GCM is a stream cipher -- it encrypts using CTR mode, which turns a block cipher primitive into a stream cipher. Additionally, GCM is an AEAD mode, which means the authentication is nicely built in (so you don't have to worry about how to handle it, because the mode itself specifies how to do it in a secure way). The IV does not need to be secret. However, ...


1

It's not ECB, but you "invited" another mode of operation. The best idea to describe your algorithm is as a stream cipher with an other function than XOR to interleave your key stream with the plaintext: The "IV key hash" generates a key stream like a good stream cipher should, and encrypting the plaintext with the key stream block is like XOR in a normal ...


3

What you have devised is no longer ECB. ECB encrypts multiple blocks using the same key. The reason we have modes of operation is so that we can encrypt multiple blocks using the same key in a way that is secure, that is identical blocks of plaintext do not encrypt to the same ciphertext block, among other properties. What you have devised uses a different ...


2

Commandline openssl enc normally does Password Based Encryption which derives the actual key, and IV (although IV is ignored for ECB), from the password or passphrase you enter, using a variant of PBKDF1. To get "raw" encryption you must specify the key in hex with -K (uppercase), in which case -nosalt is irrelevant (because it applies only to PBKDF). Except ...


4

First I will start with AES-CTR. This is a mode which turns a block cipher into a stream cipher. Since AES has a 128-bit block size, the output of the primitive is in blocks of 16 bytes. If you have a 3 byte message, 3 bytes is kept from that block to encrypt the plaintext via XOR. A broken implementation may not truncate. CTR requires a Nonce, which is ...


1

The general answer is "no, you can't authenticate someone over a wire unless they know some secret information." The only way to authenticate someone is to have them do something that no one else can do. If you're trying do to it by just sending messages between the parties, the only way I can do something that someone else can't is if I know something they ...


1

No. One of the most important principles of cryptography is that knowing the encryption scheme cannot help someone attempting to decrypt the material without the key. The encryption used seems to be a reasonably well-written implementation of several standard algorithms, for which no practical attacks are known. Finding a way to crack these would be a major ...


1

For CBC mode, the IV can be generated in any manner where it would be unpredictable to an attacker from one message to the next. In practice that means a random number generator of some kind. Since the block size is 128-bits, the probability of IV repeat before the key expiration is negligible. The CBC IV is visible to an attacker viewing your ciphertext; as ...


0

I think the best reference for the exact way block modes work is the Wikipedia article on the matter: http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation (They can be found in a lot of books, Wiki is just easier to reach). Regarding the IV exchange, AES by itself doesn't do such a thing. Generally, secret exchange is done using asymmetric ...


1

NIST specifies the paired hash digest size beat least twice the key size of AES, therefore: AES-128 is paired with at least SHA-256 or SHA-512/256 AES-192 is paired with at least SHA-384 AES-256 is paired with SHA-512 SHA3 hash functions will be added to the list in the future The reason being that the collision and preimage resistance of the hash ...


2

Well, there are two potential key recovery attacks against HMAC (assuming a reasonable hash function): Brute force the key; that is, take a valid (Message, MAC) pair, and try every possible key, and look for a key that gives that MAC for that Message Brute force the internal hashing state immediately after processing the IPAD/OPAD; here, you would take a ...


1

With OpenSSL the forward cipher for EVP_aes_265_xts is AES 256. The key being 512 bits, internally split into two 256 bit keys for each of the AES 256 ciphers used within the XTS mode of operation.


-1

This is easily cracked if you encrypt Bitmap Picture with CBC mode cipher since the 128 bits data block will be the same on bitmap pixels.


0

No, that's not possible as long as the security of AES as a block cipher is not weakened. In CTR mode a counter is encrypted using AES, and the result of that is XOR'ed with the plaintext. The counter actually consists of a nonce part and a counter part. Both the nonce and counter are known by a possible attacker. If anybody would just be encrypting zeros ...


0

As the commenters have said, it is impossible to answer without many more details about your particular implementation, but here is some background on Rijndael (pronounced 'rain-doll') that might help. Rijndael is the family of ciphers on which AES is based. AES is defined as Rijndael[1] with a block size of 128 bits and key lengths of 128, 192 and 256 bits. ...


1

Yes, if your encryption algorithm is reasonable secure. Given fixed length messages (in your case the ciphertext), CBC-MAC is a secure MAC scheme, meaning that an attacker, without knowing the key, cannot produce a valid message-tag pair with non-negligible probability. Furthermore, according to this paper, Encrypt-then-MAC is the best procedure, while ...


2

If a MAC is encrypted using CTR specifically then specific bits can still be flipped by an attacker. So although the MAC isn't known, specific bits can still be altered in transit. This may allow certain attacks, depending on the error handling of the receiver of the protected messages. [The question I cannot readily answer is if such a small authentication ...


1

Your scheme does mean that the server as a passive participant can't read the data, but if your threat model includes the server trying to get access to the data you'll need to do more. tylo mentions the server (or one of its agents) attempting to join a group, but it could probably also MITM the process of another user joining the group (by returning a ...


1

Your questions: if all the clients leave the group (at which moment they delete K from their local store), all the information on the server will be useless as nobody has K anymore if Client2 comes online for the first time and another group member is not online it will not be able to obtain K and will not be able to decrypt any of the data stored on ...


1

No, this is not a typical way to go. Actually Encrypt-then-MAC would be the best way to go, attaching the MAC (in this case a CMAC) as is to the encrypted data. Before starting the decryption, you would first check the MAC. Even in this setup using two different keys - one for the AES encryption and one for the CMAC - should be used. Finally I am confused ...



Top 50 recent answers are included