Hi Parch, I'm basically going to shamelessy rip Handbook of Applied Cryptography on this. Chapter 11 covers Digital Signatures.
11.2.2 Digital Signature Schemes with Appendix require the Message as an Input to Verification process... DSA, ElGamal, and ESIGN are examples of such as scheme. 11.2.3 Digital Signature Schemes with Recovery is a digital signature scheme for which a priori knowledge of the message is not required for the verification process. Examples are RSA, Rabin, and Nyberg-Ruppel. There are other schemes available such as One Time Signatures (11.6), Arbitrated Signatures (11.7.1) (trusting a third party), Blind Signatures (11.8.1) (prevents the party who wants to sign the message from seeing the message), and Undeniable Signatures (11.8.2) (does not require cooperation of the signer). Note 11.6 Most Digital Signature Schemes with Recovery are applied to Messages of fixed length, while Digital Signature Schemes with Appendage are applied to Messages of arbitrary length. Note 11.14 All Digital Signature Schemes with Recovery can be modified to provide a Digital Signature Scheme with Appendage. It's too bad the converse of 11.14 is not stated (I choose my words here). I'm not sure if the converse is possible. If you don't have Handbook of Applied Cryptography, you may want to pick it up. I use it often (as you can probably tell by this message). It does lack some topics, but it does a great job overall. Jeff On 6/14/07, Parch <[EMAIL PROTECTED]> wrote: > > So basically, there is no 'message recovery' because you are supposed > to append the signature to the message in the first place, and the > message is not recovered from the signature. And one just uses a > signature verifier to automatically check that the message is hashing > to the verification value. > > On Jun 12, 11:26 pm, "Jeffrey Walton" <[EMAIL PROTECTED]> wrote: > > Hi Parch, > > > > > I do not understand the 'no such beast' reference at all, is that an > > > in joke to those who have read the book? Is it the to do list that > > > isn't? > > > > I suppose more formally, I'm not aware of such a primitive in the > > context of DSA. There are two types of Signature Schemes: one is > > appendage, the other such as RSA 'folds' the message into the > > signature. Hopefully others will be able to correct me and point you > > towards a DSA SS with Recovery. > > > > > Finally, the 3rd link was not very obviously useful, as I can find no > > > example code for ECDSA itself in any of the links. > > > > General Protoype code for licensing schemes. If you can't use DSA, > > perhaps RSA could be helpful. > > > > Jeff > > > > On 6/12/07, Parch <[EMAIL PROTECTED]> wrote: > > > > > > > > > Thank you for the answer on SHA. I was wondering how the compiler was > > > picking a default algorithm, and after you said to check the source, I > > > did again, and realised it was happening through a forward declare, > > > something I hadn't seen for template structs before: > > > > > template <class EC, class H = SHA> > > > struct ECDSA; > > > > > I do not understand the 'no such beast' reference at all, is that an > > > in joke to those who have read the book? Is it the to do list that > > > isn't? > > > > > Finally, the 3rd link was not very obviously useful, as I can find no > > > example code for ECDSA itself in any of the links. > > > > > thanks, > > > Parch > > > > > > Correct, but it is not a Crypto++ limitation. > > > > Seehttp://groups.google.com/group/cryptopp-users/browse_thread/thread/36... > > > > > > > Firstly, I wonder if there is any special reasons for not > > > > > implementing it, or is it just on the to do list? > > > > > > Referring to Handbook of Applied Cryptography > > > > (http://www.cacr.math.uwaterloo.ca/hac/), there is no such beast. > > > > > > > But it seems like ECDSA is set up to do its own hashing by > > > > > default (is it using SHA?). > > > > > > If I recall, ECDSA use SHA1 (160 bits). See eccrypto.h and eccrypto.cpp. > > > > > > Perhaps the following may be of help for finding samples for use in > > > > your system:http://www.cryptopp.com/wiki/External_Samples > > > > > > Jeff > > > > > > On 6/12/07, Parch <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, > > > > > I am new to using Crypto++, enjoying the puzzle of figuring out how it > > > > > all works. I have a couple questions about best use of ECDSA. > > > > > > > I am thinking of using the digital signatures with elliptic curves for > > > > > a product licensing scheme. I just tried to do ECDSA with message > > > > > recovery. Unfortunately, this doesn't seem to be implemented. Firstly, > > > > > I wonder if there is any special reasons for not implementing it, or > > > > > is it just on the to do list? Secondly, I wonder how to solve my real > > > > > problem. Let me explain what I was attempting: > > > > > > > When I wrote this code, I was considering transmitting recoverable > > > > > plaintext, but I was originally considering sending half of the > > > > > plaintext (the other half is read from the local machine, and must be > > > > > shared between parties prior to licensing), hashing the plaintext > > > > > parts together, and then using ECDSA to encrypt that hash to produce a > > > > > signature to send with the half plaintext. But it seems like ECDSA is > > > > > set up to do its own hashing by default (is it using SHA?). > > > > > > > Am I getting tangled up because I assumed I would be able to compare > > > > > plain-texts, with verification, where in fact I could be comparing > > > > > hashes, and using the ECDSA Signer/Verifier in a much simpler way? > > > > > > > And finally Wei Dai, this library is amazing. I would enjoy reading > > > > > general stuff about your education, how you learned to write amazing > > > > > C+ > > > > > + code, why you designed Crypto++ this way, and so on. > > > > > > > thanks, > > > > > Parch > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [EMAIL PROTECTED] More information about Crypto++ and this group is available at http://www.cryptopp.com. -~----------~----~----~----~------~----~------~--~---
