4

PKCS#1 contains 4 padding schemes, of which only 2 are suitable for encryption, but only of small data blocks (like up to hundred bytes): the modern RSAES-OAEP, and the obsolete RSAES-PKCS1-v1_5 (which drawbacks include being harder to guard against decryption oracle attacks on the padding). PSS, aka RSASSA-PSS, is strictly for signature. For comfortable ...


3

there may be a simple transformation to go between the (e,cryption adn decryption) keys This answer gives an example with AES, a Substitution/Permutation Cipher (but note that AES has a few other differences between encryption and decryption). That also applies to Feistel ciphers in their common form where the final round does one less (or more) swap that ...


3

A relevant example where you usually don't use the same key for encryption and decryption is actually AES (and any SPN-based cipher for that matter). The simplest point here would be that for AES you'd normally store your expanded key in order of usage in memory (to help with things like prefetching). However this would mean that the e.g. 11 round keys are ...


2

The salt should be different for each user. It is therefor far more secure to attach the salt to the encrypted file than to have a fixed "salt". A fixed vale for the entire system, often called a "pepper" will still allow attacking multiple accounts together. To ensure you can't attack multiple accounts together use a different salt for ...


1

Yes. By any modern definition of a secure cipher, it can safely be used many times with the same key (the OTP can't safely reuse its pad/key, thus is not a proper cipher). Leaving a lot of formalism aside, RSAES-OAEP of PKCS#1v2.2 is a secure asymmetric cipher, which security is proven (to some degree, under some hypothesis including perfect implementation) ...


1

You shouldn't be concerned if you use PKCS#1 v2 encryption padding - the OAEP. OAEP, the Optimal Asymmetric Encryption Padding guarantees that even the slightest difference in raw plaintext (in your case, your symmetric keys) will result in huge difference in padded plaintext.


1

One can store all the information as IV||encryptedData||tag as concatanated in a blog object ( though there is a limit for the size of a column). But not the key. The key must never be stored with the data itself. This simply a bad way for security since there is no need to store the data as encrypted . If an attacker can access the data we can assume that ...


1

I wrote something similar in C using SHA256 several years ago and it also passed all the DieHarder tests. I intended to use it as a stream cipher in a project that employed variable length data, i.e. conversational messages, where both sides remained synchronised and therefor could continue calling off blocks of pseudo-random numbers for use with XOR. Other ...


1

Your alternate method has an expensive public key operation for each push message. While the first protocol does a key exchange just once per subscription and then continues with a symmetric key. If in the key exchange both sides authenticated themselves (Or at least the Application) the user can rely on this, if authenticated encryption is used it still a ...


1

First of all, let us look at what AAD is; it is a string that must be presented both at encryption and decryption; if the decryptor presents the wrong string, the decryption fails. Why is this useful? Because AAD can be understood as "encryption context". We typically use the same keys to encrypt several messages. What AAD prevents is the ...


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