Challenge: The following go code implements the ECDSA signatures but it has a devastating bug. To give you a small tip an adversary by exploiting the bug can write a code snippet to enforce the API to sign two arbitrary messages with the same private signing key. In reality that can happen by having an adversary obtaining signatures on different messages by the buggy backend signature library intercepting public traffic. Using only publicly available information (signatures and public keys) you can use it to extract the secret signing key and sign messages on your own!!! Can you find it ? The main code shows an example API on how to sign messages with the underlying ECDSA lib. You homework is to print out the secret key (not by copy pasting it) and verifying it is equal to the original one. Hints :hand_with_index_and_middle_fingers_crossed: Write in pensil and paper the equations in order to extract the nonce from the two signatures and then use that nonce $k$ to extract the secret key $x$ from the signature by identifying the bug in the code. Apply in code the equations by issuing 2 signatures in arbitraty messages. //based on https://arm-software.github.io/golang-utils/pkg/crypto/ecdsa.html package main

Architecture Users/Accounts on Namada Vault accounts on Namada and Eth Ethereum contracts Protocol Blockchain A(initiator) with tokens $a,b,c$ (namada) Blockchain B(destinator) with tokens $d,e,f$ (ETH20-Eth)

Private Blockchain Bridge Iraklis Leontiadis https://leontiad.github.io/ Anoma Summer Retreat 2022 Walkthrough Bridges Private bridge

Intro With Facebook enhanced message abusive report protocol a line of research work designed message franking protocols, which are faster, more secure and operate in different settings[citations]. All those schemes follow an all-or-nothing approach whereby if the sender has sent according to the receiver an abusive message the latter in order to verifiably report it to a third party platform it is forced to open the entire plaintext message to the platform thus giving away confidentiality and privacy. That sounds acceptable at a first view. Imagine in real world you are receiving a box parcel with inappropriate content from a known sender. Then you go to the police department with the parcel and you file a report for that specific sender. Alas, what if the sender has attached in in the box parcel personal objects refering to information you do not want to reveal to anyone - including police authorities? E.g the sender has marked with a non-erasable marker your credit card numbers and pins or a very personal picture which cannot be detouched from the original object. In that case the receiver would be relunctant in proceeding in any form of reporting. The authors in [citations] addressed the aforementioned issue with privacy preserving message franking protocol. Namely throughout a per block encrypting and commiting the privacy of the message is not completely given away, since only the abusive blocks of the emssage are opened to a third party. In [a] the aurhors used a merkle tree to prove membership of a block as part of an entire message that has been sent from the sender to the receiver. The high level idea is to commit to each block with a different key and during the reporting phase the third party verifies consistency only for the open blocks be the receiver and not the entire message. Similarly in [b] the authors presented a solution using vector commitments for selective opening. Both solutions minimize privacy exposure of the message only to the required blocks that the abusive information is being present. However in extreme scenarios an adversary can potentially craft special messages that include a private sensitive bait such a pin number or a password to the abusive blocks, hoping the sender will not open that block to the third party as the private bait is confidential. Under that extreme circumstances the receiver of the abusive blocks is willing to ideally open only at the level of bits the ctafted abusive content and skip the private bait inside that block. A first solution would be to follow the vanilla approach of [a,b] at the granularity of the bit level. Encrypt and commit to each bit separately. However, that would be prohibitive in terms of storage and network overhead. Real Private Franking Model Sender, Receiver, Third party

Vocabulary/ Notations Seed phrase: seed password: pwd symmetric encryption/decryption (AES) key: ek master private/public wallet signing keys: msk,mpk Low Level Functionality: Wallet.createMSK(rnd)->msk,mpv:

Parfin product allows asset managers, fund institutions and any financial entity to manage their digital assets trough parfin products: plug n play and terminal. Throughout a web interface clients can trade and manage their digital assets by connecting their exchanges (e.g: Binance, Coinbase), banks accounts (e.g: BTG, Genial), or OTC desks (Genesis, FTX, B2C2) Roles During the lifetime of Parfin products we identify the following roles that can communicate with Parfin infrastructure starting from entities with less information available towards more powerful users. External entity (A): An external entity with no access to Parfin network perimeter. Parfin user (B): A Parfin employee with access to Parfin network. Parfin client ( C ): A client who is authorized to access Parfin. Parfin admin (D): A Parfin user setting up accounts for clients.

:::success :100: Goal: :rocket: :rocket: :rocket: :rocket: :rocket: :rocket: :books: Tasks: Review existing open source TMPC libraries: Axelar, Taurus, ZenGo, Kryptology : check if libraries are modularly extendable in order to build on top other cryptographic protocols,