CryptoPad: 3-Party Asynchronous Communication
3-Party Asynchronous Communication with Perfect Secrecy based on balancing the middle party Chosen Value of m: m = 3 GitHub Repo: Link Team Members Adnan Jakati Dhanraj Chavan Mayank Ramnani Claims Our protocol ensures perfect secrecy. Theoretical maximum pad wastage in worst-case scenarios is limited by a function of d, particularly improving on the baseline split approach of 2n/3. Wastage in the worst case scenario (d undelivered messages) is min(n, 3*d) Scenarios: Scenario (a): Only one, randomly chosen, party repeatedly sends L-length messages -> Pads wasted: 3*d Scenario (b): Only two, randomly chosen, parties repeatedly send L-length messages, where the decision of who sends the next message is also randomly chosen. -> Pads wasted: 2.5d (average case) Scenario (c): Each message is sent by a randomly chosen party out of the 3 parties. -> Pads wasted: 2.7d (averaged across 10000 runs) Maximum wastage across all possible usage schedules: 3d Informal Explanation N is the number of pads available. These are shared between all the parties, with each party having the same list at the start of the protocol. For m=3, there will be 3 parties. If the available pads are treated as a list, the first party (A) will use pads from the left, moving right; second party (B) will use the pads in the middle, third party (C) will use the pads starting from the right end of the list, moving left. As pads are used, they are removed from the available list of the sender. When messages are sent, the index of the pad used is sent along with them so that decryption at the receiver is possible. The receiver also updates its available list of pads and removes the pads whose index it receives since they have been used elsewhere. This protocol needs to stop a client from sending a message when available_pads_at_client <= 3d to avoid breaking perfect secrecy. Thus, max wastage is of 3d pads. Rigorous Description (Pseudocode) initialize N pads as a shared list among all parties set m = 3 // number of parties set d // security parameter for stopping condition define party A: uses pads from left to right define party B: uses pads from the middle define party C: uses pads from right to left each party maintains its own available_pads list, initially equal to the shared list function send_message(sender, receiver, message): if length(sender.available_pads) ≤ 3d: abort transmission // stop sending to maintain secrecy pad_index = select_pad(sender) pad = sender.available_pads[pad_index] encrypted_message = encrypt(message, pad) send (encrypted_message, pad_index) to receiver remove pad_index from sender.available_pads function receive_message(receiver, encrypted_message, pad_index): if pad_index not in receiver.available_pads: abort // integrity failure pad = receiver.available_pads[pad_index] message = decrypt(encrypted_message, pad) remove pad_index from receiver.available_pads return message function select_pad(party): if party is A: return leftmost available index if party is B: return middle available index if party is C: return rightmost available index Explanation This pseudocode describes a secure communication protocol where three parties (A, B, and C) share a list of N one-time pads. Each party selects pads uniquely to avoid conflicts: ...