COMP 2711H: Lecture 26
Date: 2024-10-30 08:48:22
Reviewed:
Topic / Chapter:
summary
❓Questions
Notes
Roadmap to RSA
- 
RSA: attempt- currently: we have public encryption key 
- and private decryption key
 
- 
- pick random until MMI in field is found
 
- problem: all knowing can compute
- can we make it harder?
- and rely on the fact: factorization of large number is hard
 
 
- currently: we have public encryption key 
- 
Factorization problem- inputs: number  w/  digits
- (i.e. composite)
 
- output: "a" factorization s.t.
- algorithm 1
for (a = 2; a < N; ++a) if (N % a == 0) return (a, N / a)- simple analysis: trying at most values
- actual runtime: if  and 
 
- algorithm 2: checking primality
for (a = 2; a < √N; ++a) if (N % a == 0) return false return true- run time: won't terminate in decades, even if
 
- integer factorization: tried for 100s of years
- no one "knows" the efficient solution
- nor was proven
- RSA: depends on this fact
 
 
- inputs: number  w/  digits
RSA
- 
RSA algorithm- named after Ron Rivest, Adi Shamir, and Leonard Adleman
- key generation
- pick two large primes: (secret)
 - all calculations:
 - pick , let 
- computation of : requires factorization of 
- prevents the previous attack
 
- no proof: RSA assumption
- only given , computing is hard
 
 
- computation of : requires factorization of 
- announce
 
- encryption / decryption
- ()
- 
- 👨🏫 if message  is sent: one can take  of the message and \
- then factorize it
 
- 
- where
 
 
- 👨🏫 if message  is sent: one can take  of the message and \
 
- 👨🏫 is  necessary?
- with CRT, to have
- it is sufficient to have:
- 
- then 
- (instead of )
 
 
- again, RSA assumption:
- given and of many
- one cannot decrypt any message unless  are known
- 👨🏫 knowing or : leads to finding another and
- 👨🏫 knowing , you can directly decrypt it!
 
 
- vulnerabilities exist for "special cases" (not general case)
- e.g. for format , etc.
 
 
- 
Proof of security- Bob: holds 
- publishes
 
- Alice: compute
- Eve: cannot compute
- 👨🏫 meet our friend: Dave
- Dave: can manipulate the message over channel
 
- Alice: sends , encrypted for Bob
- then: 
- thus Dave: can replace message with
- potential vulnerability
 
 
- with traditional email protocol: such vulnerabilities can be manipulated
- (without digital signature)
- e.g. fake email services
- 👨🏫 you can claim to be other people / email address
- just don't use my email for it :p
 
 
 
- Bob: holds 
Digital Signature
- 
Digital signature- let be a message
- 
- invalid / valid
 
- property: only Alice can sign
- yet, everyone can verify signature given
 
- let verification  encryption (as all can do)
- and let sign decryption (as only Alice can do)
 
 
- 
RSA signature- simply using RSA encryption / decryption for digital signature
- a "safer" signature, thus:
- whenever sending message, attach digital signature on the way, too
 
- similar vulnerability exists
- 👨🏫 you must ensure that message: following a particular format
- e.g. starting with 10 0s- or starting with: I am Alice and my message is: {msg}
- multiplication of two messages: results in invalid (protocol wise) message
 
- or starting with: 
 
- e.g. starting with 10 
 
- furthermore, you must use different key for encryption & signature
- as signing = decrypting
- publishing signature of a message = publishing decryption of a message
 
 
- 
Example situation- now Alice, having:
- secret: 
- i.e. Alice's secrete key for encryption / signature
 
- public:
 
- secret: 
- to send  from Alice to Bob:
- compute 
- 👨🏫 actually: using instead
 
- let (concatenation)
- let
 
- compute 
 
- now Alice, having:
- for bob to receive 
- 👨🏫 can do it the other way: encrypt-and-then-sign or so
- but ensure that you are using a correct key and modulus
- as separate modulus exist for a pair of keys!
- common error found in the blockchain course
- wrong modulus results in a garbage value