Compressing BLS signature with a hash function
It seems to me, that it should be possible to hash BLS signature to achieve significant space saving. Here is how it could work:
Assuming we have a pairing-friendly elliptic curve with two generator points $G_1$ and $G_2$. Let's say my public key is $P = p cdot G_1$, where $p$ is my private key. The standard BLS signature of message $m$ would be:
$$
S = p cdot H(m)
$$
where, $H$ is a hash function that maps the message into the subgroup defined by $G_2$. The verification of the signature is done using a pairing function $e$ as follows:
$$
e(P, H(m)) stackrel{?}{=} e(G_1, S)
$$
If we use a curve such as BLS12-381, the size of the signature could be 96 bytes. But what if we redefine the signature as:
$$
s = H_2(e(G_1, p cdot H(m)))
$$
where, $H_2$ is a cryptographic hash function (e.g. SHA256). The verification can then be done as follows:
$$
H_2(e(P, H(m))) stackrel{?}{=} s
$$
Not only is the signature now only 32 bytes, but it also takes only 1 pairing to verify.
The obvious drawback is that signatures can no longer be aggregated, but I'm wondering if there are any other issues with using this scheme.
bls-signature
asked Dec 17 at 17:34
irakliy
284110
add a comment |
It seems to me, that it should be possible to hash BLS signature to achieve significant space saving. Here is how it could work:
Assuming we have a pairing-friendly elliptic curve with two generator points $G_1$ and $G_2$. Let's say my public key is $P = p cdot G_1$, where $p$ is my private key. The standard BLS signature of message $m$ would be:
$$
S = p cdot H(m)
$$
where, $H$ is a hash function that maps the message into the subgroup defined by $G_2$. The verification of the signature is done using a pairing function $e$ as follows:
$$
e(P, H(m)) stackrel{?}{=} e(G_1, S)
$$
If we use a curve such as BLS12-381, the size of the signature could be 96 bytes. But what if we redefine the signature as:
$$
s = H_2(e(G_1, p cdot H(m)))
$$
where, $H_2$ is a cryptographic hash function (e.g. SHA256). The verification can then be done as follows:
$$
H_2(e(P, H(m))) stackrel{?}{=} s
$$
Not only is the signature now only 32 bytes, but it also takes only 1 pairing to verify.
The obvious drawback is that signatures can no longer be aggregated, but I'm wondering if there are any other issues with using this scheme.
bls-signature
asked Dec 17 at 17:34
irakliy
284110
add a comment |
It seems to me, that it should be possible to hash BLS signature to achieve significant space saving. Here is how it could work:
Assuming we have a pairing-friendly elliptic curve with two generator points $G_1$ and $G_2$. Let's say my public key is $P = p cdot G_1$, where $p$ is my private key. The standard BLS signature of message $m$ would be:
$$
S = p cdot H(m)
$$
where, $H$ is a hash function that maps the message into the subgroup defined by $G_2$. The verification of the signature is done using a pairing function $e$ as follows:
$$
e(P, H(m)) stackrel{?}{=} e(G_1, S)
$$
If we use a curve such as BLS12-381, the size of the signature could be 96 bytes. But what if we redefine the signature as:
$$
s = H_2(e(G_1, p cdot H(m)))
$$
where, $H_2$ is a cryptographic hash function (e.g. SHA256). The verification can then be done as follows:
$$
H_2(e(P, H(m))) stackrel{?}{=} s
$$
Not only is the signature now only 32 bytes, but it also takes only 1 pairing to verify.
The obvious drawback is that signatures can no longer be aggregated, but I'm wondering if there are any other issues with using this scheme.
bls-signature
asked Dec 17 at 17:34
irakliy
284110
It seems to me, that it should be possible to hash BLS signature to achieve significant space saving. Here is how it could work:
Assuming we have a pairing-friendly elliptic curve with two generator points $G_1$ and $G_2$. Let's say my public key is $P = p cdot G_1$, where $p$ is my private key. The standard BLS signature of message $m$ would be:
$$
S = p cdot H(m)
$$
where, $H$ is a hash function that maps the message into the subgroup defined by $G_2$. The verification of the signature is done using a pairing function $e$ as follows:
$$
e(P, H(m)) stackrel{?}{=} e(G_1, S)
$$
If we use a curve such as BLS12-381, the size of the signature could be 96 bytes. But what if we redefine the signature as:
$$
s = H_2(e(G_1, p cdot H(m)))
$$
where, $H_2$ is a cryptographic hash function (e.g. SHA256). The verification can then be done as follows:
$$
H_2(e(P, H(m))) stackrel{?}{=} s
$$
Not only is the signature now only 32 bytes, but it also takes only 1 pairing to verify.
The obvious drawback is that signatures can no longer be aggregated, but I'm wondering if there are any other issues with using this scheme.
bls-signature
bls-signature
asked Dec 17 at 17:34
irakliy
284110
asked Dec 17 at 17:34
irakliy
284110
asked Dec 17 at 17:34
irakliy
284110
asked Dec 17 at 17:34
irakliy
284110
asked Dec 17 at 17:34
irakliy
284110
284110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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.
answered Dec 17 at 17:43
poncho
90.2k2140233
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
});
});
}, "mathjax-editing");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f65941%2fcompressing-bls-signature-with-a-hash-function%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Dec 17 at 17:43
poncho
90.2k2140233
add a comment |
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.
answered Dec 17 at 17:43
poncho
90.2k2140233
add a comment |
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.
answered Dec 17 at 17:43
poncho
90.2k2140233
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.
answered Dec 17 at 17:43
poncho
90.2k2140233
answered Dec 17 at 17:43
poncho
90.2k2140233
answered Dec 17 at 17:43
poncho
90.2k2140233
answered Dec 17 at 17:43
poncho
90.2k2140233
90.2k2140233
add a comment |
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f65941%2fcompressing-bls-signature-with-a-hash-function%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
