Embed Notice

HTML Code

<blockquote style="position: relative; padding-left: 55px;"><section><a href="https://mitra.vpclmulqdq.moe/objects/018e53ad-da40-a281-0e59-7bdd40c18e32">Grey Area (greyarea@mitra.vpclmulqdq.moe)'s status on Tuesday, 19-Mar-2024 08:31:42 JST</a><a href="https://mitra.vpclmulqdq.moe/users/greyarea" title="greyarea@mitra.vpclmulqdq.moe"><img src="https://gnusocial.jp/avatar/160416-48-20230815135216.webp" width="48" height="48" alt="Grey Area" style="position: absolute; left: 0; top: 0;">Grey Area</a><div><a href="https://mitra.social/objects/018e5348-7007-c5fe-1e55-82771c5587be" rel="in-reply-to">in reply to</a><ul><li></ul></div></section><article><p><a href="https://mitra.social/users/silverpill">@silverpill</a></p><p>In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.</p><p>As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.</p><p><a href="https://github.com/ongardie/dissertation">https://github.com/ongardie/dissertation</a><br><a href="https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html">https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html</a></p></article><footer><a rel="bookmark" href="https://gnusocial.jp/conversation/2837944#notice-5635736">In conversation</a><time datetime="2024-03-19T08:31:42+09:00" title="Tuesday, 19-Mar-2024 08:31:42 JST">about 8 months ago</time> <span>from <span><a href="https://mitra.vpclmulqdq.moe/objects/018e53ad-da40-a281-0e59-7bdd40c18e32" rel="external" title="Sent from mitra.vpclmulqdq.moe via ActivityPub">mitra.vpclmulqdq.moe</a></span></span><a href="https://mitra.vpclmulqdq.moe/objects/018e53ad-da40-a281-0e59-7bdd40c18e32">permalink</a><h4>Attachments</h4><ol><li><label><a rel="external" href="https://gnusocial.jp/attachment/792220">Untitled attachment</a></label><br></li><li><article><header><div>No result found on File_thumbnail lookup.</div><h5><a href="https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html">Two-Round Threshold Schnorr Signatures with FROST</a></h5><div> from <span>Christopher A. Wood</span></div></header><div>This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol.
FROST signatures can be issued after a threshold number of entities cooperate to
compute a signature, allowing for improved distribution of trust and
redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic
hash function. This document specifies a number of ciphersuites to instantiate FROST using different
prime-order groups and hash functions. One such ciphersuite can be used to produce signatures
that can be verified with an Edwards-Curve Digital Signature Algorithm (EdDSA, as defined in RFC8032)
compliant verifier. However, unlike EdDSA, the signatures produced by FROST are not deterministic.
This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</div><footer></footer></article></li></ol></footer></blockquote>

Corresponding Notice

Embed this notice
Grey Area (greyarea@mitra.vpclmulqdq.moe)'s status on Tuesday, 19-Mar-2024 08:31:42 JSTGrey Area
in reply to
- silverpill
@silverpill
In a permissioned setting (assume 0 malicious actors, and only need to be crash fault tolerant rather than Byzantine fault tolerant), just use Raft or something.
As far as N-of-M threshold signatures goes, FROST isn't too bad to implement.
https://github.com/ongardie/dissertation
https://cfrg.github.io/draft-irtf-cfrg-frost/draft-irtf-cfrg-frost.html
In conversationabout 8 months ago from mitra.vpclmulqdq.moepermalink
Attachments
1. Untitled attachment
2. No result found on File_thumbnail lookup.
  Two-Round Threshold Schnorr Signatures with FROST
  from Christopher A. Wood
  This document specifies the Flexible Round-Optimized Schnorr Threshold (FROST) signing protocol. FROST signatures can be issued after a threshold number of entities cooperate to compute a signature, allowing for improved distribution of trust and redundancy with respect to a secret key. FROST depends only on a prime-order group and cryptographic hash function. This document specifies a number of ciphersuites to instantiate FROST using different prime-order groups and hash functions. One such ciphersuite can be used to produce signatures that can be verified with an Edwards-Curve Digital Signature Algorithm (EdDSA, as defined in RFC8032) compliant verifier. However, unlike EdDSA, the signatures produced by FROST are not deterministic. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Public

Embed Notice

HTML Code

Corresponding Notice