Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Usage: sender uses the *public* key of the recipient to encrypt the message receiver uses her *private* key to decrypt the message encryption does not provide integrity protection!

Rivest, Shamir, Adelman can be used for both encryption and digital signatures use small e to optimize encryption/verification Pitfalls: don’t use the same key to encrypt and sign; decrypting c is the same operation as signing c ! not good with small messages; if modular reduction doesn’t occur (good chance with small e), the plaintext can be recovered by simple (non-modular) e-th root computation; =&gt; PKCS#1 applies padding in fact any kind of structure in the message seems to facilitate attacks; messages should be protected against that using suitable “encoding”; including padding =&gt; use PKCS#1 v2.1 – OAEP padding

allows to establish a shared, secret value over an unprotected communication channel used to establish a secret session key for further communication (DH handshake) doesn’t provide authentication of the parties =&gt; doesn’t protect against the man-in-the-middle attack small subgroup attack –small order g the shared secret is in that subgroup, if the group is small enough, it can be searched for the secret =&gt; solution: safe primes p = 2q + 1; q prime

a.k.a “message digest” one-way : hard to find the input for given output collision resistant : hard to find two distinct inputs with the same output used a lot in MACs and digital signatures used for file “fingerprints”: md5sum, sha1sum

lower-level API, processes input in arbitrary chunks can get digest value in progress, I.e can continue with updates after a #digest call can clone a digest in progress (#copy) can be queried for #blockSize and #digestSize and current #messageLength can reuse algorithm instances after #reset

- bound to the key and to the data being signed (it won’t validate with any other data)

digest encoding is to expand the digest to match the bit-size of n destroy any structure that the encoded bytes might have seed a random generator with the digest and use as many bytes as possible