Subject: [Ace] feedback on draft-selander-ace-object-security-02: how to reduce signature encoding size by almost 16 octets (22% improvement)

From: Rene Struik <[email-masked]>
Date: Fri, 21 Aug 2015 10:34:20 -0400

Dear colleagues:

I had a brief look at draft-selander-ace-object-security-02 and looked 
into signature sizes, where the idea would be to look for 
non-cryptographic fields where one may obtain encoding size savings.

It seems that one can shave off 14 octets of context info compared to 
the currently suggested encoding, when using ECDSA. This virtually 
eliminates the encoding size gap between "short Schnorr" and "full-size 
Schnorr" schemes (48 octets vs. 64 octets), essentially by not encoding 
the public key of the signer, since it is recoverable from the signature 
itself.

The same technique also applies to "full-size Schnorr" (as on the table 
with CFRG) or any similar signature scheme, provided one does not 
include the signer's public key in the information that is hashed with 
the signature. In those cases, the public key is recoverable from the 
signature and, e.g., certificate chains can leave out public keys in 
all-but-one of the certs in the chain. Leaving out the public key does 
not have a security impact (in the so-called "multi-user setting").

So, there is lots of low-hanging fruit that would allow reducing the 
encoding size of signatures, without possibly weakening the signature 
scheme itself.

Details:

If one would not include the public key in the information that is 
hashed with the signature (i.e., follows b) below) and sends the message 
info separately (i.e., uses "detached content" - Section 4.1.2.1), and 
uses CSM-style encoding, then one gets a signature-size of 66 octets, 
which one can squeeze down to 65 octets (compared to 79 octets figure 
mentioned in Annex E.2).

Thus, one can save 14 octets in the encoding of the header and signature 
compared to what is in the current draft, under a mild condition on the 
signature scheme (which - BTW - holds for ECDSA already, so there is 
FIPS Pub 186-3 precedence here):

Total size: 66 octets (can be squeezed down to 65 octets)
a) CSM Header Parameters (2 octets [but only 1 octet, if one optimizes 
this for ECDSA or, e.g., "Schnorr" -- see note below]):
- ALG (8 bits) --- ECDSA or, e.g., "Schnorr w/o. truncation";
- CL (5-bit) -- context identifier length is equal to zero, since public 
key of signer can be reconstructed from signature itself'
- SL (3-bit) -- sequence number length is equal to zero, since replay 
protection is provided by nonce in the message that is signed and not by 
the signature itself;
- CID (0 octets) --- no need, since public key reconstructed from 
signature itself
- SEQ (0 octets) -- no need, since freshness is provided by nonce in 
message and not part of signature scheme security services
NOTE RS: in Table 5, the CID and SEQ are supposed to be non-empty octet 
strings. Not sure why this is, since context may be defined implicitly 
if signature scheme allows this. Moreover, one can leave out length 
fields CL and SL if these are uniquely derived from signature scheme 
used. This would result in Optimized CSM Header with 1 octet length only.
b) Signature (64 octets):
- encoding of Schnorr w/o. truncation @ 256-bit security level

Details on public key reconstruction (w/ ECDSA):
Context: signature (R,s) over message m, with signer's public key Q; 
verification equation: R=(1/s)(eG+rQ), where e=H(m), r=f(R).
Input: m, (R,s)
Output: Q
-- computation: Q=(1/r)(sR-eG), where e=H(m), r=f(R)

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 21 Aug 2015 15:13:15 +0000

Hi Rene

I am confused...where in the draft-selander-ace-object-security-02 do they mention to send the public key along with the message. The Context Identifier according to my understanding is just an identifier and not the public key itself (see F.1.1 "an identifier indicating which security context was used to integrity protect the message, and may be used as  an identifier for a secret key or a public key.  (It may e.g. be the hash of a public key.). In the case where the public key is implicitly derived fromteh signature,one may need to check against a hash to verify if it's the expected public-key.

The savings on the nonce (SL/SEQ) seem to be artificial by shifting it into the payload.

Correct me if I am wrong.

Regards
Sandeep

> -----Original Message-----
> From: Ace [mailto:[email-masked]] On Behalf Of Rene Struik
> Sent: Friday, August 21, 2015 4:34 PM
> To: [email-masked]
> Subject: [Ace] feedback on draft-selander-ace-object-security-02: how to
> reduce signature encoding size by almost 16 octets (22% improvement)
>
> Dear colleagues:
>
> I had a brief look at draft-selander-ace-object-security-02 and looked into
> signature sizes, where the idea would be to look for non-cryptographic fields
> where one may obtain encoding size savings.
>
> It seems that one can shave off 14 octets of context info compared to the
> currently suggested encoding, when using ECDSA. This virtually eliminates
> the encoding size gap between "short Schnorr" and "full-size Schnorr"
> schemes (48 octets vs. 64 octets), essentially by not encoding the public key
> of the signer, since it is recoverable from the signature itself.
>
> The same technique also applies to "full-size Schnorr" (as on the table with
> CFRG) or any similar signature scheme, provided one does not include the
> signer's public key in the information that is hashed with the signature. In
> those cases, the public key is recoverable from the signature and, e.g.,
> certificate chains can leave out public keys in all-but-one of the certs in the
> chain. Leaving out the public key does not have a security impact (in the so-
> called "multi-user setting").
>
> So, there is lots of low-hanging fruit that would allow reducing the encoding
> size of signatures, without possibly weakening the signature scheme itself.
>
> Details:
>
> If one would not include the public key in the information that is hashed with
> the signature (i.e., follows b) below) and sends the message info separately
> (i.e., uses "detached content" - Section 4.1.2.1), and uses CSM-style
> encoding, then one gets a signature-size of 66 octets, which one can squeeze
> down to 65 octets (compared to 79 octets figure mentioned in Annex E.2).
>
> signature scheme (which - BTW - holds for ECDSA already, so there is FIPS
> Pub 186-3 precedence here):
>
> a) CSM Header Parameters (2 octets [but only 1 octet, if one optimizes this
> for ECDSA or, e.g., "Schnorr" -- see note below]):
> - CL (5-bit) -- context identifier length is equal to zero, since public key of
> signer can be reconstructed from signature itself'
> protection is provided by nonce in the message that is signed and not by the
> signature itself;
> - CID (0 octets) --- no need, since public key reconstructed from signature
> itself
> - SEQ (0 octets) -- no need, since freshness is provided by nonce in message
> and not part of signature scheme security services NOTE RS: in Table 5, the
> CID and SEQ are supposed to be non-empty octet strings. Not sure why this
> is, since context may be defined implicitly if signature scheme allows this.
> Moreover, one can leave out length fields CL and SL if these are uniquely
> derived from signature scheme used. This would result in Optimized CSM
> Header with 1 octet length only.
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Rene Struik <[email-masked]>
Date: Fri, 21 Aug 2015 11:28:53 -0400

Hi Sandeep:

I did not suggest that draft-selander-ace-object-security-02 sends the 
public key along with the message.

The key identifier in the message (CID) serves the purpose of 
identifying the public key of the originator of the signature. As I 
suggested in my email, with ECDSA and various other signature schemes, 
this identifier is not necessary, since the public key of the signer can 
be directly reconstructed from the signature itself. This is independent 
of the particular encoding in the CID (whether the public key itself, a 
hash, or a Subject ID). As you suggested, indeed, signature verification 
would rely on checking whether the reconstructed public key corresponds 
with (a representation of) the public key on file, but that is a 
device-internal check and has no impact on messaging itself.

My email illustrated that there may be much to be gained by looking into 
cleverly encoding strings, while using an existing signature scheme, 
before suggesting "tinkering" with signature schemes themselves.

I hope this helps.

Rene

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 21 Aug 2015 15:31:49 +0000

Thanks Rene for the clarification, it helps clears my confusion.

Regards
Sandeep

> Sent: Friday, August 21, 2015 5:29 PM
> To: Kumar, Sandeep; [email-masked]
> Subject: Re: [Ace] feedback on draft-selander-ace-object-security-02: how
> to reduce signature encoding size by almost 16 octets (22% improvement)
>
> Hi Sandeep:
>
> I did not suggest that draft-selander-ace-object-security-02 sends the public
> key along with the message.
>
> The key identifier in the message (CID) serves the purpose of identifying the
> public key of the originator of the signature. As I suggested in my email, with
> ECDSA and various other signature schemes, this identifier is not necessary,
> since the public key of the signer can be directly reconstructed from the
> signature itself. This is independent of the particular encoding in the CID
> (whether the public key itself, a hash, or a Subject ID). As you suggested,
> indeed, signature verification would rely on checking whether the
> reconstructed public key corresponds with (a representation of) the public
> key on file, but that is a device-internal check and has no impact on
> messaging itself.
>
> cleverly encoding strings, while using an existing signature scheme, before
> suggesting "tinkering" with signature schemes themselves.
>
> I hope this helps.
>
> Rene
>
> > I am confused...where in the draft-selander-ace-object-security-02 do they
> mention to send the public key along with the message. The Context
> Identifier according to my understanding is just an identifier and not the
> public key itself (see F.1.1 "an identifier indicating which security context was
> used to integrity protect the message, and may be used as  an identifier for a
> secret key or a public key.  (It may e.g. be the hash of a public key.). In the
> case where the public key is implicitly derived fromteh signature,one may
> need to check against a hash to verify if it's the expected public-key.
> >
> >> Subject: [Ace] feedback on draft-selander-ace-object-security-02: how
> >> to reduce signature encoding size by almost 16 octets (22%
> >> improvement)
> >>
> >> Dear colleagues:
> >>
> >> I had a brief look at draft-selander-ace-object-security-02 and
> >> looked into signature sizes, where the idea would be to look for
> Schnorr"
> >> schemes (48 octets vs. 64 octets), essentially by not encoding the
> >> public key of the signer, since it is recoverable from the signature itself.
> >>
> >> CFRG) or any similar signature scheme, provided one does not include
> >> the signer's public key in the information that is hashed with the
> >> signature. In those cases, the public key is recoverable from the
> >> all-but-one of the certs in the chain. Leaving out the public key
> >> does not have a security impact (in the so- called "multi-user setting").
> >>
> >> hashed with the signature (i.e., follows b) below) and sends the
> >> message info separately (i.e., uses "detached content" - Section
> >> 4.1.2.1), and uses CSM-style encoding, then one gets a signature-size
> >> of 66 octets, which one can squeeze down to 65 octets (compared to 79
> octets figure mentioned in Annex E.2).
> >>
> >> Thus, one can save 14 octets in the encoding of the header and
> >> signature compared to what is in the current draft, under a mild
> >> condition on the signature scheme (which - BTW - holds for ECDSA
> >> already, so there is FIPS Pub 186-3 precedence here):
> >>
> >> a) CSM Header Parameters (2 octets [but only 1 octet, if one
> >> optimizes this for ECDSA or, e.g., "Schnorr" -- see note below]):
> >> - CL (5-bit) -- context identifier length is equal to zero, since
> >> public key of signer can be reconstructed from signature itself'
> >> protection is provided by nonce in the message that is signed and not
> >> by the signature itself;
> >> message and not part of signature scheme security services NOTE RS:
> >> in Table 5, the CID and SEQ are supposed to be non-empty octet
> >> strings. Not sure why this is, since context may be defined implicitly if
> signature scheme allows this.
> >> Moreover, one can leave out length fields CL and SL if these are
> >> uniquely derived from signature scheme used. This would result in
> >> Optimized CSM Header with 1 octet length only.
> > The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended recipient,
> please contact the sender by return e-mail and destroy all copies of the
> original message.
>
>
> --

---

From: Göran Selander <[email-masked]>
Date: Thu, 27 Aug 2015 10:05:19 +0000

Hi Rene

Potential optimizations are always interesting, let’s go through your
proposals.

>which one can squeeze down to 65 octets (compared to 79 octets figure

The CSM header in the current draft contains essentially Algorithm (ALG),
Context Identifier (CID) and Sequence Number (SEQ). ALG is assumed to be
an 1 byte encoding of the cipher suite, the two latter are of variable
length defined by the application: CID: 1-32 bytes, SEQ: 1-8 bytes. To
allow parsing of this variable length header there are length indications
of these fields which consume in total 1 byte. The minimum CSM header is
thus 4 bytes, so with 64 bytes signature the minimum total security
overhead with the current CSM format is 68 bytes.

The "79 octets" you refer to in Annex E.2, do you mean "77 octets” i.e.
the last entry in Table 7?

Note that the numbers in Annex E are based on the assumption of an 8-byte
CID and a 3-byte SEQ, i.e. a 13 byte header, not the minimum 4 byte header.

>- ALG (8 bits) --- ECDSA or, e.g., "Schnorr w/o. truncation";

If you assume that ALG should encode whether a particular algorithm has
explicit or implicit context identifier and different types of replay
protection, you may need more than 8 bits.

>key of signer can be reconstructed from signature itself'

So some bit here may be moved from this into ALG.

>protection is provided by nonce in the message that is signed and not by

See below.

>- CID (0 octets) --- no need, since public key reconstructed from

I agree the minimum CID could be 0 bytes instead of currently 1 byte.

Since there are applications where more than one key is in use, just
allowing a simple enumeration indicating which of the candidate keys could
be useful instead of always having to calculate the public key.

>message and not part of signature scheme security services

I’m missing something in the reasoning here and in SL above.

- One interpretation is using the random part of the ECDSA signature - r,
are you considering to use that for replay protection?

- Another interpretation is that you assume that a nonce is added to the
message which is going to be signed. In that case I don’t see how bytes
are saved in transmission.

Irrespective of how the nonce is transported, storing and verifying
against a large numbers of nonces seems less optimal than sequence numbers
for very constrained devices. How many nonces would you recommend to cache?

If we want to support both nonces and sequence numbers as candidate means
for replay protection we also need to encode which of these are being used
in addition to how large they are. Alternatively we build that encoding
into the algorithm, but then we need to expand the ALG field.

>-- computation: Q=(1/r)(sR-eG), where e=H(m), r=f(R)

I agree calculating candidate public keys from signed message may be
useful in certain applications and may reduce the need to send a long
context identifier. But this computation also has a cost and would add to
the processing overhead if done each time.

Summary:

Good point: If the signature algorithm allows calculating a public key
from signed message that could be used in trading message size with
computational effort. The current CSM format supports a minimum 1 byte
context/key identifiers. You propose that should be 0 bytes and I agree
that could be allowed as an option. With that change to current CSM the
minimum overhead would reduce from 68 to 67 bytes, compared to your
proposed 65 bytes.

You propose to replace sequence numbers in the current CSM format with
nonces. I'm not convinced that nonces are feasible for replay protection
in constrained devices in general. For applications where devices can
search through a large cache of nonces, and provided we can reuse nonces
that are already included somehow I can see a potential gain here of the
order of a few bytes on average. Note that for sequence numbers we only
need to send the significant part, we can remove initial zeros. If we
should support multiple replay protection mechanisms that also needs to be
encoded and adds some complexity to handle.

Finally, the current assumption is that the message format we should use
is COSE, for which CSM is just a benchmark, so a similar analysis of COSE
would make even more sense. I think that many of the optimizations you
propose to CSM risk being "lost in translation” to COSE.

Regards
Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 27 Aug 2015 10:24:19 +0000

Hi Rene

>before suggesting "tinkering" with signature schemes themselves.

Out of the three proposals for reducing signature size suggested by people
to CFRG, I wouldn’t call any of those “tinkering”.

I agree that much can be done in terms of optimizing encoding, but when it
comes to whether say 64/70 = 91% or 64/65 = 98% of the security overhead
consists of signature (which is what we discussed in the previous mail),
then there is clearly an impact if we can reduce the signature size with
25%. So I think it is good news that the CFRG chairs endorse further
investigations on this.

Regards
Göran

>> I am confused...where in the draft-selander-ace-object-security-02 do
>>they mention to send the public key along with the message. The Context
>>Identifier according to my understanding is just an identifier and not
>>the public key itself (see F.1.1 "an identifier indicating which
>>security context was used to integrity protect the message, and may be
>>used as  an identifier for a secret key or a public key.  (It may e.g.
>>be the hash of a public key.). In the case where the public key is
>>implicitly derived fromteh signature,one may need to check against a
>>hash to verify if it's the expected public-key.
>>
>>>to
>>>into
>>>the
>>>public key
>>>the
>>>encoding
>>>hashed with
>>>signature
>>>this
>>>public key of
>>>by the
>>>signature
>>>message
>>>uniquely
>> The information contained in this message may be confidential and
>>legally protected under applicable law. The message is intended solely
>>for the addressee(s). If you are not the intended recipient, you are
>>hereby notified that any use, forwarding, dissemination, or reproduction
>>of this message is strictly prohibited and may be unlawful. If you are
>>not the intended recipient, please contact the sender by return e-mail
>>and destroy all copies of the original message.
>
>
>--

---

From: Rene Struik <[email-masked]>
Date: Thu, 27 Aug 2015 09:59:15 -0400

Hi Goran:

Please see brief feedback below.

Best regards, Rene

> CID and a 3-byte SEQ, i.e. a 13 byte header, not the minimum 4 byte header.
RS>> If I understand correctly, this means that the header has 13=8+3+2 
octets, in which case one indeed comes to 77 octets (if signature is 64 
octets).
If one elides the SEQ and CID entries and only uses the 1-octet ALG 
field, one can squeeze this into 65=64+1 octets. If one feels one needs 
a hint for SEQ (3 octets), this would become 68 octets.
In the first case, one gains 12 octets compared to what is in the draft; 
in the latter case, this becomes 9 octets, *without* having to touch the 
signature scheme itself.
<<RS
> protection, you may need more than 8 bits.
RS>> I would be surprised if one would need more than 256 options for 
ALG. With ECDSA (or other signature scheme that does not hash the public 
key of the signer along), one can automatically elide any fields eluding 
to which public key is used, so does not need to introduce any options 
(# options=1).
<<RS
> be useful instead of always having to calculate the public key.
RS>> I would be curious about an example here. (Of course, there are 
trade-offs between signature encoding size and computation details: this 
was the entire point of my email.)
<<RS
> into the algorithm, but then we need to expand the ALG field.
RS>> The signature scheme usually only provides for non repudiation, not 
for replay protection. If one uses encryption+signing or signing, one 
can often compress the nonce in sent messages, e.g., when (a) the 
recipient more or less knows this (example 1: nonce related to time 
attribute (6tisch case); example 2: reconstructable from stored nonce 
value for sender and compressed nonce); (b)  the signature has a 
challenge response element to it (example: use of signatures in any 
challenge response protocol, including authenticated key agreement (TLS, 
etc.)).
<<RS
> the processing overhead if done each time.
RS>>
The computational cost of signature verification (with ECDSA example) is
(a) with public key reconstruction: compute Q:=(1/r)(eG-sR) and compare 
with representation of stored value;
(b) without public key reconstruction: find Q; compute R:=(1/s)(eG+rQ) 
and check that R corresponds with r.
Thus, the computational cost of (a) is roughly the same as with (b), 
whereas the communication cost of (b) may be higher {since one needs to 
know which Q to use for verification}.
<<RS
> propose to CSM risk being "lost in translation” to COSE.
RS>>
Perhaps. My note was aimed at stimulating looking for "smart" ways to 
reduce communication overhead, while being able to reuse existing 
signature schemes (which I have not seen before - all spec text assumes 
amorphous blobs and discards structure one may be able to exploit).
<<RS

---

From: Rene Struik <[email-masked]>
Date: Thu, 27 Aug 2015 10:11:48 -0400

Hi Goran:

> to CFRG, I wouldn’t call any of those “tinkering”.
RS>> My email to the ACE list did not refer to CFRG efforts: it 
illustrated how one could do some smart encodings using existing schemes 
(using ECDSA, which is FIPS Pub 186-2), without having to tinker with 
signature schemes. As an aside, there is some concern that "short" 
Schnorr schemes would have security pitfalls. With BSI's Schnorr scheme, 
the hash function is *not* allowed to be truncated below the curve size. 
Personally, I speculate it would be possible to safely reduce the 
signature size a little bit, but not much (1 3/4 times the curve size, 
vs. 2 times, i.e., saving of 8 octets: 56 octets vs. 64 octets), which 
may not be worth the hassle and within the realm of cost-cutting in the 
external overhead (as my email was about).
<<RS
> 25%. So I think it is good news that the CFRG chairs endorse further
RS>> I am not sure whether those numbers are correct (in my previous 
email I came to 12 octets or 9 octets compared to what you had in that 
draft. This aside, of course, ideally one would like to have zero octet 
signature size overhead (one always wants less). However, there are 
technical limitations of what can be achieved. Minimum possible might be 
32 octets signature overhead, if using ECPVS and if message has 
sufficient redundancy (but this requires educated users of the scheme 
to, indeed, ensure that this redundancy is actually there [which I am 
not hopeful they will do -- too much moral hazard]). That scheme does 
require overhead to indicate the public key of the signer, though, so 
part of the size gain is lost in the context of its use.
<<RS

---

From: Göran Selander <[email-masked]>
Date: Thu, 27 Aug 2015 16:56:21 +0000

Hi Rene,

Brief comments inline.

>in the latter case, this becomes 9 octets, *without* having to touch the

[GS: When you write “what is in the draft” your refer to the example in
Appendix E which is not minimal but arbitrarily setting some values to
length of context identifier and sequence number to be able to compare
different message formats in the tables. If you are interested in
comparing optimized formats I think you should use the minimum value of
CSM format as defined in Appendix C.]

>to which public key is used, so does not need to introduce any options

[GS: See below.]

>>>public
>>>by

[GS: This relates to what is being identified with the CID; resource,
host/device, principal, etc. It is up to application to define what is
being identified. If we leave out the CID we may overload other identifier
used, and conversely with the CID in place we may omit or abbreviate other
identifier.]

>challenge response protocol, including authenticated key agreement (TLS,

[GS: 1) in general we can’t assume synchronised time as in 6tisch. 2) I’m
not familiar with this case, please provide reference. 3) we can’t assume
this in general, as it it may be 1-pass.]

>know which Q to use for verification}.

[GS:If I’m not mistaken, the calculated public key is not necessarily
unique. In ECDSA there are two options and more if the cofactor is not =
1. That in itself would require more computations.]

>amorphous blobs and discards structure one may be able to exploit).

[GS: And I agree calculating instead of sending the public key may be
useful.]

Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 27 Aug 2015 17:14:32 +0000

>external overhead (as my email was about).

GS: OK, thanks for clarifying.

>draft. 

GS: See my recent reply.

>This aside, of course, ideally one would like to have zero octet

GS: Just on the last point, while public key transport in signed message
is nice, in 
many applications public keys may be transported once or out of band, and
then an abbreviated identifier may be sufficient.

>>>>>looked
>>>>> signature sizes, where the idea would be to look for
>>>>>non-cryptographic
>>>>> fields
>>>>>optimizes
>>>>> is, since context may be defined implicitly if signature scheme
>>>>>allows
>>>>> this.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 28 Aug 2015 07:35:45 +0000

Hi Rene

Not trying to pick on individual points but I find the below argument incorrect

> (b) without public key reconstruction: find Q; compute R:=(1/s)(eG+rQ) and
> check that R corresponds with r.
> Thus, the computational cost of (a) is roughly the same as with (b), whereas
> the communication cost of (b) may be higher {since one needs to know
> which Q to use for verification}.
> <<RS
> >

[SK>]If you believe that in case (b) you need to have a context to identify which Q to use for verification, you similarly need the context in case (a) to verify if the computed Q should be relevant for the particular use of the message. I do not see how otherwise you would manage in a device with multiple Q's (or hashes of Q's).

On a general point,  one would be doomed if they trust a raw public key with the message that was also used to sign the message. So there is no point sending the public key in the message. Only way is to send (implicit) certificates or out-of-band provisioning of the public keys.

Regards
Sandeep

---

From: Göran Selander <[email-masked]>
Date: Fri, 28 Aug 2015 08:17:56 +0000

Hi Sandeep,

If you for some reason can easily provision (out of band or by other
trusted delivery) hash of a public key but not public key itself, then
recovering the public key through the first signed message is an
optimization.

If everything else stays the same (security, computational cost, etc.) I
suppose you could use (a) by default.

Regards
Göran

On 2015-08-28 09:35, "Kumar, Sandeep" <[email-masked]> wrote:

>>whereas
>[SK>]If you believe that in case (b) you need to have a context to
>identify which Q to use for verification, you similarly need the context
>in case (a) to verify if the computed Q should be relevant for the
>particular use of the message. I do not see how otherwise you would
>manage in a device with multiple Q's (or hashes of Q's).
>
>On a general point,  one would be doomed if they trust a raw public key
>with the message that was also used to sign the message. So there is no
>point sending the public key in the message. Only way is to send
>(implicit) certificates or out-of-band provisioning of the public keys.
>
>Regards
>Sandeep
>
>addressee(s). If you are not the intended recipient, you are hereby
>notified that any use, forwarding, dissemination, or reproduction of this
>message is strictly prohibited and may be unlawful. If you are not the
>intended recipient, please contact the sender by return e-mail and
>destroy all copies of the original message.

---

From: Rene Struik <[email-masked]>
Date: Fri, 28 Aug 2015 10:01:56 -0400

Hi Goran/Sandeep:

Obviously, one should not skip the check as to whether the reconstructed 
public key corresponds to the (representation of the) public key. This 
policy check is device-internal, though, and can indeed be realized via 
comparing a compressed image of the public key (hash or perhaps even 
16-octet locally stored value).

As already said, this is one technique one could use to potentially 
economize on context information (by using the mathematical structure of 
the signature itself). As said in my original email on this, this can 
also be used to elide public keys in certificates in a certificate 
chain, since each of these can be reconstructed and put back in their 
"original spot" (if certificate verification is done in a serial fashion).

Best regards, Rene