bitcoin おかげさまで、FromHDDtoSSD v3への統一から10日が経過しました。皆様のご協力に感謝申し上げます。
おかげさまで、FromHDDtoSSD v3への統一から10日が経過しました。皆様のご協力に感謝申し上げます。v3では、ブロックチェーン技術を活用し、ユーザ主権のプライバシー重視の検査や復旧機能を提供することを目指して開発を進めています。従...
BLOCKCHAIN
bitcoin 
bitcoin 暗号通信用のクラスが、検証を含めて完成しました。
暗号通信用のクラスが、検証を含めて完成しました。これにより、暗号メッセージ付きトランザクションと、Web3ブロックチェーン・ファイル転送サービスを実装する準備が整いました。片方は数日以内にサービスを提供できるかな。ファイル転送サービスは20...
bitcoin サイドチャネル攻撃をわかりやすく例えます
それでは、サイドチャネル攻撃をわかりやすく例えます。まず、暗号通貨に対するこの攻撃の目的は秘密鍵を奪う事、それだけです。この「サイド」という言葉通り、システムを破壊する等が目的ではありません。ではなぜ、この攻撃で秘密鍵が漏洩してしまうのか。...
bitcoin Schnorr集約署名で束ねた鍵から対称鍵を作る。
Schnorr集約署名は楕円曲線で動作しておりますので、対称鍵を簡単に作る事ができます。それは、自分側の秘密鍵と相手側の公開鍵をスカラー倍にするだけで得ることができます。相手側の公開鍵には相手側の秘密鍵が含まれているため、そこに自分側の秘密...
bitcoin 秘密鍵を大量に束ねることができるSchnorr集約署名を用いることで、どんなにサイドチャネル攻撃を試みても全く成功しない環境を構築することなどが重要
ハッキングに対する最も有効な対抗措置は、攻撃者に「これは不可能だ」と認識させることです。それには、秘密鍵を大量に束ねることができるSchnorr集約署名を用いることで、どんなにサイドチャネル攻撃を試みても全く成功しない環境を構築することなど...
bitcoin ブロックチェーン版への完全移行についてのご案内
ブロックチェーンのセキュリティに関する鍵の開発において、集約による特性により「安全性」と「署名検証安定性」を確実に確認することができました。これに基づき、FromHDDtoSSDはブロックチェーン版へ完全に移行することを決定いたしました。こ...
bitcoin Schnorr集約署名を高速化(5000鍵を3秒以内): v3.74.14をリリース
これで完成です。次回リリース予定のSORA-QAI ver3では、新しいブロックチェーンベースのアプリケーションを導入します。このアプリケーションは、暗号のメモ帳を基盤にした機能を提供します。しかし、この機能はただのメモ帳ではありません。少...
BLOCKCHAIN [ECDSA+Schnorr(5000keys)+量子AI耐性]鍵に、実用性のあるデータを搭載してみます。
ブロックチェーンには搭載サイズに厳しい制限があります。それでも、事前の調査で520バイトを25個連結する手法で結構な量のデータを搭載可能なことがわかっております。あまり載せ過ぎても同期が重くなりますが、トークンやハッシュの管理なら十分です。...
bitcoin Schnorr署名 5000キー集約でいきます。
これと量子＆AI耐性をマルチシグすれば、怖いものはないと判断しました。実際のデータなどをブロックチェーン経由で記録する場合は、この集約を必須といたします。ハッカーなどを相手では50や100などの中途半端な集約ではいけません。やはり5000で...
bitcoin ウォレット内部にあるECDSA鍵をSchnorr署名集約クラスのXOnlyPubKeysにpushしていくだけで検証できるようになりました。本実装ではY座標偶数の制約はありませんので、ECDSAの代わりにSchnorr署名を使うことができます。
この方向性で、75個のECDSA鍵を集約して実稼働できる見通しが立ちました。Y座標偶数の制約がないため、ウォレット内部から自由に選んでpushして集約することができます。便利です。
bitcoin 効率的なマルチシグ: 鍵の集約、便利です。お試しの100個の鍵によるECDSA-Schnorr署名マルチシグであっても瞬時に生成です。そこで、マルチシグの集約をサポートするためOP_CHECKSIGADDは不要で、この集約で常に署名するOP_CHECKSIGAGGを新規で投入します。
100個の鍵によるマルチシグ。非線形性のECDSAでは100個の公開鍵と署名が必要になるため、そのサイズは約10KBになります。サイズが大きくなるのに加え、OP_CHECKSIG同等の処理が100回必要となるため、検証側の負担が大きくなりま...
bitcoin 最終考察(その7)の前に……「Schnorr署名」が完成しました。BIP340にある公開鍵Y座標に対する制約解除(ウォレット内部の鍵を制限なくそのまま利用可能)、nonceは乱数、Verifyは完全一致(X座標だけではなくY座標も一致)、集約により100個のマルチシグであっても公開鍵32バイト固定、署名64バイト固定になります。
OpenSSLとlibsecp256k1で検証を重ねていた「Schnorr署名」が完成しました。テストも、計算上も問題ありません。これで自信を持って実装できます。魅力的なのは、集約により100個のマルチシグであっても公開鍵32バイト固定、署...
AIデータ復旧サービスについて [libsecp256k1で確認完了] invert(e) * privの場所です。オーバーフローが原因だったため、格納できない分をあらかじめ引き、差を取ってから、引いた分を戻す(加える)操作で確認完了です。
libsecp256k1で動かない理由がオーバーフローにある点を突き止めました。どうやら位数だとオーバーフローする仕様で、その位数から1を引いた数は格納できる内容でした。まさか、楕円曲線の定数がオーバフローするとは考えておらず、overfl...
bitcoin negの一部はOpenSSLで確実を取りました。そこは引くだけなので、使い方が違うのかな。
schnorr署名の導入のうち、eに対するnegの過程で、libsecp256k1のnegが上手く作用しないため、暫定的な処置としてその部分だけOpenSSLで代用する内容となりました。計算の内容はシンプルで、単に値を入れてnegしてから加...
bitcoin 決まった数(定数)に対するnegなので、直接、バイナリで操作することで引くことにしました。
昨日の続きです。libsecp256k1のnegが期待通りに作用しないため、BIGNUMに変換後、OpenSSLの関数で引いて、その結果をbe32でlibsecp256k1のスカラーに戻す手法があります。ただ、これはちょっと厳しいため、直接...