Cryptography for Smalltalkers 2 - ESUG 2006
•Download as PPT, PDF•
1 like•1,053 views
ESUG 2006
![Contents ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Cryptography for Smalltalkers 2 - ESUG 2006
Similar to Cryptography for Smalltalkers 2 - ESUG 2006 (20)
Cryptography for Smalltalkers 2 - ESUG 2006
- 1. Cryptography or Smalltalkers 2 Public Key Cryptography Martin Kobetic Cincom Smalltalk Development ESUG 2006
Editor's Notes
- much slower than secret key encryption: expensive operations (x^y mod z), long keys (1-8K bits) => used for key encryption/exchange, signing elliptic curve crypto (ECC) same ciphers, different number field allows much shorter keys for comparable security => faster heavily patented (www.certicom.com) some royalty free licenses for specific purposes (NIST/IETF)
- 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; => 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 => use PKCS#1 v2.1 – OAEP padding
- public key structure: n, e ciphertext size is 512 bits! (depends on the key size) private key structure: n, d p, q: CRT => 3-4 times speed up of decryption.
- you have to transfer both the encrypted key and the encrypted message
- 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 => 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 => solution: safe primes p = 2q + 1; q prime
- m – bit size of q => bit size of x (at least twice the size of symmetric key) l – bit size of p => bit size of y - Ephemeral-ephemeral DH - perfect forward secrecy (PFS)
- Ephemeral-static DH Unlike RSA with DH Bob needs ya to decrypt!
- 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
- MD-strengthening: with inclusion of the length no encoded input is a prefix of another encoded input MD-stregthening helps a lot but doesn’t completely prevent “length extension” if M2 = M1’ || X => h(M2) = h ( h (M1) || X)) M1’ means, the original M1 message padded as prescribed by the hash function possible fixes: h(h(M), M) – expensive, or h(h(M)) - weaker; MACs usually address the weakness as well
- derived from MD4 (fixing known MD4 weaknesses) broken in 2004 by Wang, Yin; furher improved by others currently collision in a few hours on common desktop PC
- higher level API, processes entire input at once both stream and byte array based parameter support
- also derived from MD4 SHA-0 broken (Wang, Yin, Yu 2004): collisions in 2**69 instead of 2**80 SHA-1 broken (Wang, Yin, Yu 2005): collisions in 2**69 instead of 2**80
- 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
- based on “discrete logarithm” problem used for signatures only signing: Generate a random per message value k where 0 < k < q (this is known as a nonce ) Calculate r = ( g k mod p ) mod q Calculate s = ( k -1 (SHA-1( m ) + x * r )) mod q Recalculate the signature in the unlikely case that r =0 or s =0 The signature is ( r , s ) verification: Reject the signature if either 0< r <q or 0< s <q is not satisfied. Calculate w = ( s ) -1 mod q Calculate u 1 = (SHA-1( m )* w ) mod q Calculate u 2 = ( r * w ) mod q Calculate v = (( g u 1 * y u 2 ) mod p ) mod q The signature is valid if v = r Note: FIPS-186-2, change notice 1 specifies that L should only assume the value 1024 forthcoming FIPS 186-3 (described, e.g., in SP 800-57) uses SHA-224, SHA-256, SHA-384, and SHA-512 as a hash function, q of size 224, 256, 384, and 512 bits, with L equal to 2048, 3072, 7680, and 15360, respectively.