# Tag Info

11

but I'm wondering if there are any other issues with using this scheme: $H_2(e(P, H(m))) \stackrel{?}{=} s$ The obvious problem is that anyone with the public key can compute everything on the left side, and hence forge a signature to any message they want.

6

That's insecure. In BLS signatures: for private key $x$ and public key $X = xP$, the signature is computed as $T = xS$, and the verification checks if $e(T, P) = e(S, X)$, which works because: $e(T, P) = e(xS, P) = e(xS, P) = e(S, P)^x$ $e(S,X) = e(S, xP) = e(S, P)^x$ If you know that $S = kP$, then you can forge a signature for a message with hash $k'$ ...

6

BLS signatures work in any so called gap group, i.e., a group where the computational version of the Diffie-Hellman (DH) problem - the CDH - is hard, but the decisional version of the DH problem - the DDH - is easy. Below I'm using the notation from the wikipedia article on BLS. Just recall, that the DDH in a group $(G, g, r)$ (where $g$ is a generator and ...

5

BLS signatures are computed by hashing the message $m$ from the message space $\mathcal{M}$ to a source group of a bilinear pairing $e: \mathbb{G} \times \mathbb{G} \to \mathbb{G}_T$ using a hash function $H: \mathcal{M} \to \mathbb{G}$ and exponentiating $h$ with the secret key $x$, i.e., a signature $\sigma$ is of the form $$\sigma := H(m)^x.$$ The hash ...

5

Well, the Boneh-Lynn-Shacham "BLS" signature scheme is currently in the process of being standardized through an Internet Draft named "draft-irtf-cfrg-bls-signature-00" (a working document of the Internet Engineering Task Force "IETF"), which you can track here. It appears Algorand might be behind this process, along with Dan ...

4

The security of pairing-based cryptography relies on the security of the elliptic curve (which is linked to the size of underlying finite field, or "base field") and of the finite extension field being used. The "Dlog security" column in the linked page is the size of the finite extension field. Its security used to be comparable to the corresponding RSA ...

3

It is not a secure hash function. For example, one can easily break the collision resistance property: let $q$ be the order of $g$, then $m$ and $m+q$ have the same hash value, $H(m+q)=g^{m+q}=g^m=H(m)$.

3

You can. Low-embedding degree may be bad due to the MOV attack, but pairing-friendly curves are particularly chosen so that the embedding degree is low but still enough to not decrease security. So any elliptic curve algorithm should be safe on the curve, not only pairing-based ones. Some observations: ECDSA if often used with NIST curves with cofactor 1. ...

3

Since $\mathbb{G}_T$ is $\mathbb{F}_{q^2}$ in the setting you are mentioning, you would have to choose them so large that your implementation will no longer have the performance one would hope for. I would recommend to switch to the asymmetric setting. Currently the probably best choice regarding performance and existence of optimised implementations is to ...

2

Let $P_1$ be generator of $G_1$ and $P_2$ generator of $G_2$. Let $f:(G_1 \times G_2)^k\rightarrow\{0,1\}$ be Ethereum pairing check operation. Given $\sigma,R \in G_1$ and $V\in G_2$ it is possible to check if $e(\sigma, P_2)=e(R,V)\vee e(\sigma,P_2)^{-1}=e(R,V)$ is true with Ethereum built-in operations, you just check check whether: $f(\sigma, P_2, -R, ... 2 Yes, in the random oracle model, the hash of a BLS signature makes a VRF essentially as secure as the BLS signature scheme (provided the verifier accepts only the unique canonical encoding of each signature). This works because BLS signatures are unique. Fix a pairing$e\colon G_1 \times G_2 \to G_T$on groups$G_1$and$G_2$of prime order. For any fixed ... 2 The setting described in that paper is an instance of a so-called “Type-II pairing” with an efficient isomorphism$G_2\to G_1$. Most efficient pairing constructions are “Type-III”, where such an isomorphism is believed not to exist. So if you take a normal implementation of the BLS12 bilinear group, this won't work: ignoring twists, you can indeed compute ... 1 You can't convert the signature output from one algorithm to another, especially not ones relying on random oracles. 1 It depends on whether the pairing is a type 1 pairing or some other type of pairing. In a type 1 pairing,$S$is a multiple of$P$. In any other type of pairing,$S$is not a multiple of$P$. 1 You cannot create a verifiable$Z$but you can create a verifiable$W$but you have to add public keys multiple times as well. So$W$can be verified using a key$PK_a + 2*PK_b + 2*PK_c + PK_d\$ if you had the same message or doing having multiple pairings for each repeated key in case of distinct messages

1

Can Bob, without interacting with Alice, generate a new aggregate signature for the entire message set, i.e. (M,s′), that validates with Alice's public key? That would be troubling if Bob could sign anything verifiable by Alice's key (on behalf Alice). if there is a simpler and more efficient method available if there is only one signer. I am mainly ...

1

There is a classic solution, applicable to any two public-key cryptosystems: deriving both private keys from a master key, which plays the role of a new common private key. Start from a master key. Derive from it and two public constants the seeds of the CSPRNGs used for the key generators of the two public-key cryptosystems (use some Key Derivation ...

Only top voted, non community-wiki answers of a minimum length are eligible