Feature #3251
closed
Allow encoder to use multiple signature types
Added by Andrew Brown about 9 years ago.
Updated about 9 years ago.
Description
In https://github.com/named-data/jndn/blob/master/src/net/named_data/jndn/encoding/Tlv0_1_1WireFormat.java#L844, the wire format encoder only recognizes certain built-in Signatures. I would like to add different Signature classes with minimal changes to the encoding code; can we add a way to register new signature types?
Here are two options:
One possibility is to delegate the encoding to the Signature itself; this would require wireEncode() and wireDecode() methods on every signature. This is simple but custom signatures may unwittingly encode incorrectly. For decoding, some map (held perhaps in a global singleton) would have to track signature codes (like Tlv.SignatureType_SignatureSha256WithRsa, etc.) and their respective implementations; this map would have to have a public register(signatureTlvCode, signature) method so that external code like ours could add other Signature implementations.
Another possibility is to keep all encoding in the wire formats and to query the Signature for a few new necessary methods (hasKeyLocator(), getTlvType()); this approach would still require a register(signatureTlvCode, signature) but perhaps at the wire format level (?). On the encode side, for example, it might look something like:
if (signature.hasKeyLocator()) {
encodeKeyLocator(Tlv.KeyLocator, signature.getKeyLocator(), encoder);
}
encoder.writeNonNegativeIntegerTlv(Tlv.SignatureType, signature.getTlvType());
Thoughts?
To clarify, you have defined your own application-specific signature algorithm and TLV type? Do you want to send a data packet with this encoding through NFD (which may not like an unrecognized signature algorithm)?
Separately, will you also need to override the signature sign and verify code?
Dear Jeff, we defined our own algorithm and application-specific key management/storage. What would be useful in our scenario is signing data packets with our application provided signature algorithm and key, and in order to do that, we were thinking about the possibility to "bypass" the KeyChain, and compute the signature directly with our algorithm.
Another alternative could be providing the KeyChain with an algorithm instance, so the KeyChain can sign/verify with it.
The idea is that the spec for the Data packet only includes fields that might need to be processed by an NDN forwarder and related network infrastructure. For example, signatures are used to set up routes and do interest/data exchange for registering a prefix with a forwarder, so signatures are part of the Data packet spec. On the contrary, even though encryption is important, it is not part of the fields of a Data packet because an NDN forwarder and related network infrastructure doesn't process encryption information, so encryption information is only in the application-specific Content field, understood by the application.
If you have an application-specific (and possibly proprietary) signature algorithm which has no meaning to the network, can you encode the signature information into the Content field?
I agree, signatures are part of the forwarding logic of NDN, and should have no other meanings. I could certainly add the signature into the payload.
One may however want to handle the keys used to sign a packet separately, using its own KeyStore implementation, and without relying on the KeyChain. Moreover, one may simply want to re-implement a MAC/Signature scheme, e.g., SignatureHmacWithSha256 using some other more efficient, or simply different, implementation (which, however, would not compromise the possibility for the network to verify the MAC using other implementations of the same algorithm). Is this currently possible?
I've also noticed that SignatureHmacWithSha256 is not supported (SygnatureType #4, http://named-data.net/doc/ndn-tlv/signature.html).
For SignatureHmacWithSha256, there is an open issue #3075 to to add support since the security library was initially designed to support asymmetric signature algorithms, and HMAC is symmetric.
For extending the library, Andrew and I had a bit of discussion about this. Signing is handled by a subclass of PrivateKeyStorage, and verifying by a subclass of PolicyManager. If you have a different implementation it is likely that you also have a different way to store the keys as well, so it makes even more sense to just implement your own PrivateKeyStorage and PolicyManager subclasses.
I'm still not entirely clear? Do you want to implement a "more efficient" version of existing signature algorithms like RSA, or do you have a new signature algorithm?
We would like to use arbitrary signature schemes to compute the data packet signature. Ideally, the use of a specific signature scheme should be independent from the way we store the keys, which could be, for example, provided to the KeyChain as a parameter of the sign method.
To summarize, what we would like to have is (1) the possibility to use new signature schemes to sign packets, and (2) to directly provide the sign method with the key to use.
Hello Moreno. I added Task #3260 to add a new Signature subtype GenericSignature. It is in the "NDN-CCL" project because it would be implemented in all CCL libraries. We will start with jNDN.
- Status changed from New to Closed
This issue has moved to Task #3260 "GenericSignature" in the NDN-CCL category (since it applies to all client libraries). Closing this issue.
Also available in: Atom
PDF
Updated by Anonymous 
Updated by