Tag Info

Hot answers tagged

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 ...


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

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 ...


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 ...


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 ...


2

That might not be speed-efficient, but for educational purpose it is possible to implement the CTR internals manually, by using the ECB mode of CNG: Set the Algorithm mode: BCryptSetProperty(hAesAlg, BCRYPT_CHAINING_MODE, (PBYTE)BCRYPT_CHAIN_MODE_ECB, sizeof(BCRYPT_CHAIN_MODE_ECB), 0) Encrypt all blocks the IV with counter with the key hKey: ...


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 ...


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

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 ...


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 ...


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 ...


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 ...


1

Actually, that's remarkably easy to show. The AES key scheduling logic is invertible: For AES-128, you can start at any round, take a specific setting for that round key, and invert it to come up with the unique AES key that generates that round key For AES-192, you can start at any round, take a specific setting for that round key (and 64 bits from the ...



Only top voted, non community-wiki answers of a minimum length are eligible