Try   HackMD

Cryptography group @Parfin

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Goal:

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Tasks:

  1. 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,
    • they support an existing sdk or they come as standalone libraries,
    • they support network stack.
  2. Organize internal Parfin meetups for cryptography education
  3. Conferences attendace: RWC
  4. Constant cryptography/security audit of Parfin stack
  5. Put critical code in Nitro enclaves(ongoing)
  6. Start networking in the community(ongoing)
  7. Update with relevant state of the art in Threshold Cryptography(ongoing)
  8. Powerpoint with competitor analysis with a nice balance in details

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →
Output:

    • Review of libs (the underlying math lib layer hasn't been reviewed)
    • Build a standalone demo (currently a rust test mod, better make an independent main executable)
    • Build a fully functional network demo
    • Integrate to parfin stack
      • Think more what needs to be done here, talk with engineering team
    • Benchmark solutions

MPC libs review

Kryptology: Coinbase (https://github.com/coinbase/kryptology):

  • Go
  • Protocols: Threshold ECDSA GG20 and DKLs18 + DKGs
  • Doc level: very poor
  • No network stack available for the moment
  • No ser/des
  • No audit
  • It is frequently updated

Taurus: https://github.com/taurusgroup/multi-party-sig

  • Go
  • Protocols: CMP, Frost (Schnorr)
  • Doc level: Documentation to set up a standalone demo
  • No network stack available for the moment
  • No ser/des
  • No audit
  • It is not updated frequently

ZenGo: https://github.com/ZenGo-X/multi-party-ecdsa

  • Rust
  • Protocols:GG18,GG20,L17,Castagnos19
  • Public audit
  • No network stack available for the moment
  • No ser/des

Axelar: https://github.com/axelarnetwork/tofn

  • Rust
  • Protocols: GG20
  • Doc level: Good
  • Audited by NCC and the Taurus interns: Adrian, Lucas
  • Ser/des and networking supported
  • SDK,Docker images, wrapped as grpc daemons to be used in production
  • Tony Arcieri is actively advising and supporting: he is the creator of rust crypto crate and very knowledgable/known/respectful in the community
  • Not used in production (claimed tests with 50+ shares)
  • It is an active project in progress which needs time for improvements and maturity:

Both tofn and tofnd are currently under active and ongoing development. Both repos were audited by NCC Group Cryptography Services on 2021-aug-10 and by Adrian Hamelink and Lúcás Meier on 2021-oct-29.

Last changed by 
 
Iraklis
0
423

Read more

ECDSA Challenge

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

Feb 19, 2023
Eth Bridge

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)

Oct 4, 2022
Private Blockchain Bridges

Retreat Italy 2022 - Anoma - PBB

Aug 18, 2022
Zero Knowledge Message Franking

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

Jul 27, 2022
Read more from Iraklis
Published on HackMD