# Tag Info

0

The case that the (encoded) message may be too long for proper encryption has already been envisioned and mitigated by the designers of the specification of the padding scheme. First note, that $k$ in fact denotes the length of the modulus $n$ - in bytes. This length is always accurate, so if $k=256$ the modulus has a bitlength somewhere in $[2041;2048]$ or ...

2

Yes, and it's devastatingly effective, too. See OAEP and other RSA/asymmetric-function padding standards. OAEP is what you should use these days so far as I am aware. PKCS#1 has other defined padding schemes also (eg PSS, PKCS1.5), only some of which are effective.

0

There exist polynomial time attacks against RSA signatures with constant padding. So, this actually does not exploit the missing check for the padding. It uses index calculus The latest paper that I am aware of in this series is http://www.dtc.umn.edu/~odlyzko/doc/index.calculation.rsa.pdf but you might also be interested in this paper: ...

2

If you were using $e=3$, then there is a well known attack by Bleichenbacher that enables the trivial generation of a signature that passes verification. This attack was never published, but is described here. Note that this attack appeared in a real vulnerability in Kindle (and some versions of Android). In any case, the attack does not work for $e=65536$. ...

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