We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

12

How does the new attack work at top level? In short They used BEAST-like Man in the Browser attack by using Cache-like attacks to perform a downgrade attack against any TLS connection to a vulnerable server. With this, they showed the feasibility of using Cache-like attacks. More detailed Even over the years, numerous mitigation techniques are ...


7

Which of these should I be using? PKCS1 v1.5 seems a bit simpler to implement. Generally you should not be implementing this yourself, there are plenty of libraries that implement these schemes out of the box. Both the PKCS#1 v1.5 padding for signature generation and PSS padding have pro's and con's which I list below. Which one you decide to use it up to ...


5

It seems that the authors of Keccak sponge (the algorithm chosen to be SHA-3) do think their SHAKE functions can directly be used for simplifying OAEP and PSS: The introduction of extendable-output functions (or XOFs, pronounced zoff) is a particularly nice feature of the standard. A XOF like SHAKE128 or SHAKE256 can be seen as a generalization of hash ...


5

There is no such thing as a PKCS#5 plain private key. PKCS#5 defines Password Based Encryption (PBE) and it is noted that this can be used to encrypt a private key. PKCS#8 does define plain and encrypted private keys. By using a parameterized object identifier that indicates one of the PKCS#5 schemes you can encrypt the private key. Which one you should ...


5

The answer is relatively simple, but I'll expand on the details of the changes from PKCS#1 2.0 to 2.1 in two additional sections below this answer. On the padding with the zero valued byte The I2OSP function - used during decryption - converts an integer to a statically sized, unsigned, big endian octet string or byte array. This function will always ...


4

Well, you are as surprised as I believe most of us are... AES-CTR and AES-CBC are "obsolete", whilst AES-CTR is used by AES-GCM. Okay, so maybe he recommends authenticated modes (which don't require making your own authentication). But those aren't obsolete, they are just harder to code properly... DH and all variants of RSA are "obsolete". Only ECDSA and ...


4

Maarten Bodewes answer is correct, but it is missing one important point. It is actually NOT secure to have randomness in PKCS#1V1.5 padded signatures, otherwise signatures could be forged via bleichenbacher's e=3 attack. Take a look at https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/ to see what happens when signature ...


4

When you're talking about RSA-1024, the "1024" refers to the bit length of n, so n is 128 bytes long. Now let's take a look at RSA decryption process : In order to recover your plaintext, you will compute \begin{align*} c^d \mod n &= m^{e*d}\mod n\\ & = m \mod n \end{align*} You can see that if $ m > n$, i.e. if $m$ is more than 128 bytes (in ...


3

When you use textbook RSA, the public key is $(e,N)$ and the ciphertext of a message $m$ is $c = m^e\bmod N$. The encryption process of textbook RSA involves no randomness; this causes the problem. It is easy to see that when having $m_1=m_2$ the ciphertexts of them $m_1^e =m_2^e \bmod N$. Deterministic encryption is not CPA-secure. When using a Padding ...


3

Now, I'm wondering about the case where an implementation does check that the hash is right-justified, but doesn't check the previous bytes at all. That case is completely broken for $e=3$ Assuming that we're still talking about exponent 3, someone could imagine that there might be a way to find a perfect cube that ends with that particular hash, thereby ...


3

Provided you follow PKCS#1 v1.5 verification exactly, and don't attempt shortcuts like checking only the hash part of the message hash representative, it should be fine. There's no security reduction to the RSA problem proven, like there is for RSA-FDH or RSASSA-PSS, and certainly no reduction to factorization, like there is for Rabin–Williams, but no ...


3

The 01 and 02 valued bytes before the PS are used for domain separation; each scheme has it's own unique value that way. For a generic cipher it is required that the method is non-deterministic. The reason is simple: otherwise you would be able to identify which messages are identical, as they would result in identical ciphertext: $$E_{pk}(p) = E_{pk}(p') \...


3

A zip file of test vectors (FIPS 186-2 Algoithm Test Vectors for RSA) can be found at the bottom of the page on NIST's site pertaining to CAVP Testing: Digital Signatures. This file contains a readme and the test vectors for X9.31RSA, RSA PKCS#1 Ver 1.5, and RSA PKCS#1 RSASSA-PSS signature generation. It looks like it does contain vectors for SHA-256.


2

The point is that you will only be able to reconstruct the seed if you know every single bit of maskedSeed and maskedDB and you will be able to decode the message only if you know every single bit of the seed and maskedDB. If an attacker gets only a single bit of maskedDB wrong, feeding it to the MGF will yield a totally different result and will not allow ...


2

The reason that you won't find much is that RSA is generally not used for bulk encryption, instead hybrid encryption is used. For RSA using PKCS #1 v1.5 padding you generally don't want to go above $2^{31}$ but hopefully significantly fewer iterations. This is because of the birthday bound on the random padding used. If the random padding is identical to an ...


2

Yes, the idea of using RSA signature as KDF can work. The KDF's key will be the RSA private key, and the other input of the KDF will be the message to sign. Other requirements: Either: The signature is post-processed by a cryptographically secure PRF, e.g. a hash (which will make the output of the KDF indistinguishable from random, and the KDF uninvertible)...


2

If you encrypt something with low entropy but use a fixed seed for OAEP, it is trivial to brute force it, and verify your guesses with public key, while randomized all or nothing padding will make verifying a guess impossible. In the context of signatures rather than encryption, it doesn't seem as severe, but you are supplying the attacker with a bunch of ...


1

It is nice that you have tested if from the first hands. The textbook RSA encryption is deterministic in the sense that given a public key $(e,n)$ and two plaintext $0 \leq m_1,m_2 < n$ if $$ c_1=\operatorname{Enc}_{k_{pub}}(m_1)$$ $$c_2 = \operatorname{Enc}_{k_{pub}}(m_2)$$ than $$c_1 = c_2 \text{ iff } m_1 =m_2.$$ We already say that textbook RSA ...


1

In practice this should be okay. The reason the padding needs to be random is that if the padding can be guessed then the attacker can start encrypting candidate plaintexts (correctly formatted with the padding) under the public key and observe if the output matches the target ciphertext. Of course if the attacker finds a match then they have recovered the ...


1

I think it actually is, lets read through chapter 8.1.1 Signature generation operation: EMSA-PSS encoding: Apply the EMSA-PSS encoding operation (Section 9.1.1) to the message M to produce an encoded message EM of length \ceil ((modBits - 1)/8) octets such that the bit length of the integer OS2IP (EM) (see Section 4.2) is at most modBits - 1, where modBits ...


1

(background) It wasv mentioned in the paper that for TLS, RSA PKCS#1 v1.5 is used to encapsulate the 48-byte premaster secret exchanged during the handshake. Does means that a random padding string PS is prepended to the 48-byte premaster secret to this formatted massage ([00] || [02] || PS || [00] || pms) before the actual RSA encryption is done? Yes, ...


1

In MFG1, the size of $T$ in octets of the provisionally generated mask is never smaller than the specified $maskLen$ at the point where we want to Output the leading $maskLen$ octets of $T$ as the octet string $mask$. That follows from the fact that $T$ was built as the concatenation of $\lceil maskLen/hLen\rceil$ hashes, each of $hLen$ octets. See the ...


1

Use HKDF to generate your random data with inputs of your private key, the message being signed, and whatever entropy you do have available (such as a real-time clock value or other time stamp). This way all random values you produce will be completely unpredictable to anyone without your private key, and will change with each message even if you have zero ...


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