# Tag Info

1

Given the choice, it is preferable to use the block encryption operation of AES, since it often faster than block decryption (never slower AFAIK). For this reason, AES-CTR is defined to use the block encryption operation of AES; that's both for AES-CTR encryption and AES-CTR decryption, which are the same operation except for IV generation/input. AES block ...

1

The one you have in hardware. Sometimes the hardware only supports block encryption (because it is sufficient for e.g. CTR), in which case that will be faster. If the hardware supports both or neither, there is probably no difference. I doubt many implementations only support decryption, but if you have one that does, that would be faster. The speed of raw ...

1

It is usually seen that decryption operations are slightly faster than encryption. But considering the working mode of AES, CTR uses same steps in both encryption and decryption. So It does not matter which one you use in CTR, both should give essentially same performance.

4

Do not invent your own authenticated encryption mode. Use a standardized one, and use a well-supported library to implement it in your code. AES-GCM, AES-CCM, AES-OCB, and AES-CBC with HMAC-SHA256 over the ciphertext are all common options. Some great direction from Matt Green here: How to choose an Authenticated Encryption mode

2

Both the AES key size and the RSA key size matter, because it's no use adding security beyond the weakest link. Here the weakest link is 2048-bit RSA, which is considered roughly equivalent in security to 100-128-bit symmetric keys (depending on who you ask). So having a password with much more than 100 bits of entropy would be fairly useless. In practice, ...

1

Let's look at some simpler relations first. I'll be sloppy with the probabilities, I'm only trying to gauge the order of magnitude. The probability that $E_{k_1}(p) = k_1$ is $2^{-128}$ for a given $p$, but must be true for some $p$ with every AES-128 key $k_1$. The probability that $E_{k_2}(p) = k_2$ for the same $p$ is $2^{-128}$ for a given $k_2$. The ...

2

ECB is not secure even with per file keys, because if two blocks of the file are identical, this is visible in the ciphertext. The only * cases where ECB is secure is encrypting completely random data or encrypting a single block per key. You should pick something more secure if your can help it. If there is literally no other option than RC4 and AES ECB, ...

1

Would there be a minimum ciphertext size that is related to the public key size? It depends on the algorithms used. An RSA signature, without any bells and whistles, is equal to the key length in size (i.e. 2048 bits for 2048-bit RSA). Likewise raw RSA encryption adds the same. So if you just use both, you add twice the key length, or 512 bytes for a ...

3

Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for ...

1

There's nothing wrong with using CTR mode to encrypt files, or anything else, as long as you make sure to use every nonce value only once. (And add authentication, if malleability would be a problem.) You could, for example, rewrite the whole file encrypting it with a new random nonce every time it's modified. Since you are assuming nonce reuse, an attack ...

1

Using the same key and IV for different, independently encrypted cells is a bad idea, regardless of which encryption algorithm you use. It would allow attackers to find either XORs of cells (with CTR) or at least equality of prefixes (with CBC). If you are going to use authenticated encryption, you need to choose whether the MAC applies to each cell ...

1

Is there a standard or at least "commonly used" format to format the result? PKCS #7 (and CMS which is a further development) describes a standard format for encrypted data. While it's mainly meant for public key encrypted data, it also has options for symmetric keys. It's rather complex due to all the features it supports, however, so unless you can ...

3

In RFC2246, if you need 12 bytes of padding total, that means that you have 11 padding bytes, followed by a padding length field. So, each padding byte has a value of 11 (0x0b), as well as the padding length field. This is implied by the requirement that the total TLSCiphertext.length must be a multiple of the block size, and this TLSCiphertext.length ...

1

Well, firstly, SHA-1 still seems to have 160-bit preimage and second preimage resistance, so using it in HMAC requires more than 128-bit AES keys to get equivalent security. AES 192 would be sufficient, but isn't used in e.g. TLS – RFC 3268 says: The AES supports key lengths of 128, 192 and 256 bits. However, this document only defines ...

14

TL;DR No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX. Long Version In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send ...

4

First, the advice: What are the best-practices to store the message length / strip away padding? Use standard padding, like PKCS#7 padding. It handles finding the length uniquely for you. Use encrypt-then-MAC to prevent padding oracle attacks. (Or better yet, don't use CBC. Use an authenticated encryption mode like GCM, or use CTR+MAC which doesn't ...

Top 50 recent answers are included