Intro to encryption exercise 11
1 / 19

Intro To Encryption Exercise 11 - PowerPoint PPT Presentation

  • Uploaded on

Intro To Encryption Exercise 11. Problem. Alice and Bob wish to play the game Paper, Rock and Scissors. What may be the problems with the game? The requirements for the games are Privacy of the choice (i.e. when someone chooses, the other party does not know his choice)

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Intro To Encryption Exercise 11' - imala

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • Alice and Bob wish to play the game Paper, Rock and Scissors.

  • What may be the problems with the game?

  • The requirements for the games are

    • Privacy of the choice (i.e. when someone chooses, the other party does not know his choice)

    • Non repudiation of the choice (i.e. when someone chooses, he can’t change his decision later)

  • Assume: known public keys for parties: eA, sA, eB,sB (for encryption, signature by Alice, Bob)

Solution choice phase
Solution – choice phase

  • Use Encrypt-Then-Sign scheme, i.e. sign the encrypted value.

  • Alice’s playout

    • Alice picks ephemeral PKCS keys etemp ,dtemp

    • Alice’s choice is denoted as Ca (“P”, “R” or “S”)

    • Alice choice:

      • SignsA(Encetemp(Ca),etemp).

  • Same goes for Bob.

Solution verification phase
Solution – Verification Phase

  • Alice provides

    • CA , randomness used for encryption

    • Why do we need to use randomized encryption?

  • Bob’s verification

    • VervA(Encetemp(CA),etemp)

  • If CA>CB (when > represents better) then Alice wins, otherwise Bob wins.


  • Why does Alice (and Bob) sign their public keys as well? Isn’t it sufficient to sign the encryption?


  • No!!!

  • From the lecture:

    • Anderson and Needham [AN95]

      • Key-spoofing attacks against EtS

      • Recipient chooses (special?) public encryption key e

      • Such that for some m, m’, e’ holds: Ee’(m’)=Ee(m)

      • E.g. RSA: m’=me/e’m’e’=me

      • With CRT, can compute e’ for any m, m’, e

      • `Collision` of encryption (inputs: public key and data)

  • Signing the public key ensures that this key was used and no other key.


  • Suggest a way for independent parties to share keys for sessions.

  • The parties may hold a long term key with only one party, for each other parties they can’t hold/generate a long term/short term key.

  • The parties may trust some other parties.

  • You may NOT use DH/RSA.


  • Use a key distribution center for generating the keys.

  • Each entity trusts the KDC and holds a symmetrical key with him.

  • The KDC shall generate the keys.

  • Example:

    • Party A wishes to communicate with party B.

    • A’s key is KA, B’s key is KB. The keys are shared with the KDC only.


  • KDC generates a key KAB

  • KDC transmits the keys using

    • ENCKA(KAB) to A

    • ENCKB(KAB) to B


  • What about authentication?

  • Should we use the same keys for encryption and authentication?

  • How may we derive keys for authentication?


  • The use of MAC is required for authentication.

  • We MUST NOT use same keys for MAC and ENC (possible key/message exposure)

  • We MAY Derive keys as follows

    • PRFKA(“Encryption”) for encryption

    • PRFKA(“Authentication”) for authentication


  • How may you refresh the keys of the KDC (and clients) to provide proactive security such that all clients are synchronized and their keys are refreshed?


  • We may use forward secrecy

    • At period t+1 client A shall replace his key KA likewise

      • PRFKA(“Refresh”||t+1)

    • The same shall be with the KDC (same protocol)

      • For each Ki in { A, B, …} do

        • PRFKi(“Refresh”||t+1)

      • done


  • Does this solution provide forward secrecy?

  • How would you change the protocol to accommodate the requirements for forward secrecy?


  • Using DH methods

  • Generate p a large prime and g a generator.

  • User A shall generate a number aand gawhich shall be his private and public numbers.

  • The KDC shall generate a number ka and gkafor each of the clients.

  • The protocol

    • Use DH between the client and server to generate the new keys

  • Show the protocol including authentication to provide secure key refresh without eve performing a man in the middle attack or discover the new key.


  • What may be the problem with a central KDC?


  • Performace may decrease when clients increase. Especially when multicast clients are present

  • Security may be a very big issue (single point of failure, master keys recovery).


  • How should you improve performance?

  • Is replication a good performance improvement?

  • How does it affects security?


  • A naïve approach may be to replicate the KDC

  • This may solve some performance issues when done properly

  • This may decrease security because of multiple exact copies of the same information.