引き続き選択的開示に関する調査論文を読んでいきます。
Selective disclosure in digital credentials: A review
本文に入っていきます。
最初のポイントは、「選択的情報開示の形態と種類、実現方法」についてです。
まず、選択的開示の方法として以下の3種類が挙げられています。
- アトミック・クレデンシャル
- 選択的開示署名
- ハッシュ値
アトミック・クレデンシャル
非常にシンプルな方法です。一つのクレデンシャルに一つのクレームのみを含むようにする手法です。
例えば、選択的開示可能なマイナンバーカードのクレデンシャルを作ろうと思ったら、名前・住所・生年月日・性別をそれぞれ別のクレデンシャルにしてしまって、必要に応じて提示するクレデンシャル自体を分ける、ということですね。
選択的開示署名
ネイティブに選択的開示をサポートしている署名形式を用いる手法です。CL署名とかBBS+なんかはこちらでしょうね。
ハッシュ値
全てのクレームを含むクレデンシャルを発行するものの値をハッシュ化する手法です。SD-JWTはこちらですね。論文中ではハッシュの方法論についても比較をしつつ解説していますので、こちらも参考になります。
他にもZKPについても語られており、ZKPとハッシュ値の組み合わせなど複合手法についても分析が行われています。
アトミック・クレデンシャルについては置いておくとして、選択的開示署名とハッシュ値の2点については方式が一覧化されています。
論文中に出てくる順番とは異なりますが、引用しておきます。
選択的開示署名の方式の概要
Article | Algorithm | Complexity | Performance | Suitability | Key sizea | Signature sizea |
---|---|---|---|---|---|---|
[69] | CL signature | High due to the use of interactive ZKP of signatures | Relatively slow due to the complex arithmetic | Suitable for systems that require anonymity features | 256 bytes | Can be in kilobytes |
[67] | ECDLREP function | Moderate complexity | Efficient due to the properties of elliptic curves | Suitable for systems where performance and compact signatures are required | 32 bytes | 64 bytes |
[72] | URS (SPS signatures) | Moderate to high (depends on specific construction) | Efficient in protocols that need to maintain structure of the message (ZKP) | Used in advanced systems where preserving message is crucial | 32 bytes | Can be in kilobytes |
[68] | Edwards curve | Low in context of other elliptic curves due to the simpler formulas | Faster calculation and better security | Commonly used in systems like EdDSA | 32 bytes | 64 bytes |
[70] | BLS signature | High due to the use of pairing based cryptography | Signature generation is slower, verification can be fast and aggregation can be done effectively | Particularly useful where aggregation of signatures is needed | 48 bytes | 96 bytes |
[71] | BBS+ signature | High due to the use of pairing based cryptography | Similar to BLS, but with more flexible signatures and message management | Suitable for multi-message systems | 96 bytes | 112 bytes |
[74] | Aggregate signatures with randomizable tags | High due to integration of randomizable tags | Efficient in scenarios where aggregation and randomization are needed simultaneously | Suitable for systems where reusability of signatures without linkability is needed | 32 bytes | Can be in kilobytes |
[79] | Redactable signatures | High due to the modifying or redacting of signatures | Typically slower due to the additional data management requirements. | Ideal for systems where document integrity is important, especially with authorized edits. | 32 bytes | Can be in kilobytes |
[77] | Unlinkable redactable signature schemes | Very high due to the combination of unlinkability with redaction | More complex and slower | Ideal for highly sensitive environments redaction | 2048 bits | Can be in kilobytes |
[75] | Tag-based aggregatable mercurial signatures | Extremely high with the combination of mercurial signatures and tag aggregation | Slower | Suited for systems with complex workflows | 2048 bytes | 5056 bytes |
- a
Depends on the chosen primitive.
ハッシュ方式の概要
Article | Algorithm | Complexity | Performance | Suitability | Static/Dynamic | Size/Overhead |
---|---|---|---|---|---|---|
[54] [55] [61] [57] | Hash commitments | Generally low because it involves one hashing operation per attribute Depends on size of credential and on hashing function used | Fast processing and verification | Static datasets where integrity is more important than confidentiality or structured proofs. | Static data | Simple proofs Large in size All hashes or disclosed messages are sent |
[56] | Polynomial commitment | Higher than regular commitments Depends on selected polynomials | Slower due to the mathematical operations required for committing and verifying attributes | Ideal for applications that require structured proof (ZKP systems) | Static data | Complex proofs with higher computation costs Disclosed data + calculated commitment are shared |
[50] [52] | HMAC (keyed-hash message authentication code) | Low because it is similar to hash commitments Requires key management | Efficient but slower than regular hash due to the key-based operations | Useful for authentication in insecure environments Ensures data integrity and authenticity | Static data | Simple proofs Large in size Added overhead due to key management |
[62] | Merkle tree | Building O(n) Updates or proofs O(log n) | Efficient for large datasets Allows partial verification | Useful for application where efficient, incremental updates and verifications are needed | Dynamic data | Proof size grows slower than the dataset |
[64] | Merkle B-tree with EC | Higher than standard Merkle tree due to multiple child nodes and added overhead of EC | EC can increase tree construction and update time Faster access for non-sequential data operations | Useful for systems where updates are frequent and there is a requirement for security | Dynamic data | Proof size grows slower than the dataset |
[63] | Merkle B-tree with encryption | Similar to standard Merkle Tree with added overhead of encryption (complexity depends on algorithm) | Encrypting can increase time for tree construction, update and verification | Useful for systems where enhanced privacy is needed | Dynamic data | Proof size grows slower than the dataset |
いやぁ、ものすごく参考になりますね。
0 件のコメント:
コメントを投稿