Get desktop application:
View/edit binary Protocol Buffers messages
[Sphinx doc begin anchor: EcSuit] Suit of <curve, hash, hash2curve_strategy>
Used in:
,ref enum CurveType
ref enum HashType
ref enum HashToCurveStrategy
[Sphinx doc begin anchor: EccProtocolProposal]
list of <curve, hash, hash2curve_strategy> suits
ref enum PointOctetFormat 点的序列化格式
Whether to enable the optimization method: secondary ciphertext truncation
[Sphinx doc begin anchor: EccProtocolResult]
The chosen suit
The chosen octet format
optimization method: secondary ciphertext truncation -1 means disable this optimization (do not truncation)
Which rank can receive the psi results. 确定 PSI 结果获取方。 NOTES: `-1`: all parties (所有机构都可以拿到交集结果) `>= 0`: corresponding rank can get the results (指定机构拿到交集结果)
https://eprint.iacr.org/2009/226.pdf Auto select the most suitable algorithm: - SHA2: select between SHA-224, SHA-256, SHA-384, SHA-512 - SHA3: select between SHA3-224, SHA3-256, SHA3-384, SHA3-512 - SM: Current only support SM3. Performance: This method is very fast, but it is susceptible to timing attacks.
Just like TryAndIncrement; but use re-hash instead of increment when try fails.
The applicable scenarios of this scheme are very limited, and the following requirements must be met: - The calculation of points on curve depends only on the x-coordinate - The usage scenario of the curve allows any hash value to be used as the initial point, even if the point is not on the curve. It is currently known that this strategy can be safely used when curve is Curve25519 and scene is ECDH. Do not choose this strategy for other purpose.
Below is IRTF CFRG hash-to-curve standard (draft): https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/ IRTF suits consist of: "CURVE_ID || "_" || HASH_ID || "_" || MAP_ID || "_" || ENC_VAR" We regard MAP_ID and ENC_VAR as a whole as HASH_TO_CURVE strategy. MAP_ID has the following methods: - "SVDW" for Shallue-van de Woestijne method - "SSWU" for Simplified SWU - "ELL2" for Elligator 2 method ENC_VAR has the following methods: - "RO" for hash_to_curve Performance: This strategy takes 12 times longer than TryAndIncrement on SM2 - "NU" for encode_to_curve Performance: This strategy takes 6 times longer than TryAndIncrement on SM2 Warning: The output of this strategy is not uniformly distributed on the elliptic curve G.
Elliptic curve point Octet-String format See SECG standard for details: SEC 1, section 2.3. https://www.secg.org/
不压缩,多个点连续存储,例如 x1||y1||x2||y2||x3||y3... x 和 y 都占用整数个 byte, 例如 255bits 的数字占用 32bytes, 小端序,buffer 最后1bit补0 对于 X25529, 本身只有 X 坐标,则多个点序列化只排列 X 坐标
ANSI X9.62 compressed format The point is encoded as z||x, where the octet z specifies which solution of the quadratic equation y is. if y is even, output 0x02||x if y is odd, output 0x03||x if point is inf, output 0x00
ANSI X9.62 uncompressed format The point is encoded as z||x||y, where z is the octet 0x04
ANSI X9.62 hybrid format The point is encoded as z||x||y, where the octet z specifies which solution of the quadratic equation y is. It's basically the uncompressed encoding but the first byte encodes the evenness of y just like in compressed format. It's designated by 0x06 and 0x07 in the first byte, and they have the same meaning as 0x02 and 0x03 in compressed.