Talk:Digital signature

src: dzone.com

Video Talk:Digital signature

Comment

Shorter:

A crypto signature decrypts to a document hash under the given user's public key, thus proving that the document was signed by the user's private key. Connelly 05:22, 21 Jul 2004 (UTC)

Update Needed. More about DKIM please.195.38.17.129 (talk) 13:38, 12 March 2009 (UTC)

NEW COMMENT: I've seen this recent attack: http://www.mirlabs.org/jias/buccafurri.pdf Anybody think that it could considered in the section about Drawbacks of digital signatures? --Preceding unsigned comment added by 79.56.88.81 (talk)

yes..I think so, it's interesting -- Preceding unsigned comment added by 79.23.115.233 (talk) 09:11, 2 March 2014 (UTC)

NEW COMMENT for the DEFINITION section regarding DIGITAL SIGNATURES:

EXISTING: It is formed by taking the hash of the message and encrypting the message with the creator's private key.

PROPOSED: It is formed by taking the hash of the message and encrypting the hash with the creator's private key. -- Preceding unsigned comment added by 68.99.180.202 (talk) 07:39, 9 June 2015 (UTC)

Maps Talk:Digital signature

Analogy to traditional signature: meaning and wording

Matt,

The analogy of digital signatures to paper ones is, subtly, not very close. That's why I used the construction 'in a sense'. It wasn't quite weasel wording. The problem is that is messy and not quite on point. I'm open to an alternative phrasing, in fact, I'd welcome one, but as it stands it's too easy to misconstrue the degree of analogy. Needs to be changed somehow.

The analogy is close enough, IMO, to serve as an analogy; have a look at Schneier's Applied Crypto book (sec 2.6); he introduces digital signatures by listing the essential five properties of physical signatures that can be achieved electronically by digital signatures. -- Matt 17:26, 18 Apr 2004 (UTC)

This is a real nuisance. Most of the legal beagles in the legislatures, at least on this side of the pond, have demonstrated some inability to get the distinction. And the legal beagles putting together position papers for the American Bar Association also failed to get it. There is an English soliciter/barrister (I'm almost colorblind on that one) named Nicholas Bohm who was (and may still be for all I know for I haven't been following this closely for a couple of years) one of the very few of these beagles who had the right scent. But he was advised closely by Brian Gladman (?) who did several reference algorithm implementations about the time of the AES break off. So there may have been reason why Bohm was better at this than most of the others.

ww 17:18, 18 Apr 2004 (UTC)

Matt, He does indeed and I remember his list. But the concern I have is based on work I did in support of a professional education seminar for lawyers here prompted by the passage of the Esignature Act of 2000. It's a swamp and I think we should be careful not to fail to convey a sense of caution here. That's what I was trying for with that phrasing. ww 18:29, 18 Apr 2004 (UTC)

geyer7 20 Dec 2005

I pulled the sentence, "(Software developers typically expect about 1 defect per 1,000 lines, unless intense efforts have been taken to raise its quality, in which case 1 defect per 1,000,000 lines is typically expected)." These numbers should be sourced and I believe it's inaccurate to say they refer to something software developers typically expect.

Where the analogy holds

In Canadian law, a secure electronic signature can be used (most) everywhere a notarized signature or Minister's signature is required. In other words, this specific form of electronic signature is considered as strong as the strongest form of "ink-and-paper" signature. (The PIPEDA S-E-S regulations can only be satisfied with digital signatures.)

Why do we care? Because there are places where the analogy isn't an analogy, it's a homology: Present a notarized signature on a paper document and a secure electronic signature on the homologous electronic document to a Canadian judge and the judge will likely conclude that for legal purposes they are they same signatures and the same documents. Neither has any greater or lesser standing that the other.

And this needs to be borne in mind when this page is rewritten, especially when the section on legality is rewritten.

Think of it this way: For anyone other than an autograph hound, a signature is of interest for its legal value. Ultimately, the same is true of digital signatures. The technology may be interesting, but, ultimately, the reason we want to get the technology (and procedures and policy) right is so that these things stand up in a court of law.

Perhaps the page needs to be broken into two overall sections: Technology (just the facts) and legality (with no overall content but references to various jurisdictions.

Alternatively, remove any subjective or legal content, and make reference to appropriate pages.

For example, repudiation is not a fact, it is a legal matter.

PeterWhittaker (talk) 17:52, 1 October 2008 (UTC)

src: pbs.twimg.com

This bit is just garbage and needs rewritten

"Unlike a traditional handwritten signature a digital signature may be generated automatically, without the knowledge of the authorized user", "paper signatures can be copied [or] created under coercion", "However, if the right software is used in the right way, including not leaking the private key, then the digital signature on some message can be created only by definite actions of the person in question, therefore validating the use of digital signatures." are all mutually exclusive.

I'm not claiming to be able to write definitively on this subject, but this just reeks...

Dtada69 Btada69 (talk) 02:23, 12 December 2013 (UTC)

src: i.ytimg.com

Evidential status

Many of the legal enactments (statute or regulation) surrounding digital signatures is concerned with their admissibility as evidence. More controversial, however, is their actual value as evidence. Unlike a traditional handwritten signature, a digital signature may be generated automatically, without the knowledge of the authorized user. However, very few can reliably prove a handwritten signature is legitmate, too, since paper signatures can be copied, created under coercion, few have handwritten signature cards to compare against, pages may have been changed after the signature was applied, etc. A digital signature is generated by complex software, operating on an operand whose nature and existence cannot be fully or directly verified by the authorized user. Whereas the existence of a digital signature can be evidentially significant in establishing that an electronic communication is uncorrupted, and that it had a certain provenance, it cannot of itself provide any evidence as to whether a particular individual intended or authorized or associated himself or herself with any such communication. In that regard, the term "signature" is potentially misleading as the engineering does not know, and may possibly not be able to coincide with, the assumptions underlying many of the legal enactments. Legal enactments which affirmatively declare that a digital signature is presumptively deemed a valid signature are at variance with the possibilities afforded by the cryptography.

However, if the right software is used in the right way, including not leaking the private key, then the digital signature on some message can be created only by definite actions of the person in question, therefore validating the use of digital signatures.

I.K. 03.12.2009: I can not agree with aforementioned doubts. If system-generated digital signature is technically possible, all comes down to credibility of implementer.

We need some practical examples here. One from my experience - in Estonia every person has digital signature linked to their personal ID-card. For usage one must have valid ID card and two PIN codes - for authentication of person and for actual signing. This kind of digital signature is for all purposes deemed more secure than handwritten signature - for example one does not have to have his his digital signature proved by notary in most if not all actions where notary is required in case of handwritten signature. This digital signature solution is cornerstone of Estonian E-State solution: for example citisens portal - https://portaal.riik.ee/x/kodanik/ - enables to access many public databases, have ones taxes declared, participate on e-elections etc. In business, for example people do not need to gather for signing mutually signed documents (Board meeting decisions etc) as after teleconference meetings documentc can either be e-mailed and signed or posted on designated central website (https://digidoc.sk.ee/) where documents can be securely stored, signed, shared etc. When signing document(s) .ddoc file is created. It has nothing to do with Microsofts .doc files. Actually, one can sign either 1 file, or several - in which case bundle is created which from onwards has appearance of one .ddoc file - until bundle is opened, in which case all files can be separately seen and read but not saved back into bundle - for obvious reasons files will lose signture after edit. File type (doc, xls, txt, jpeg) is not important, system supports all file types. --Preceding unsigned comment added by 217.159.213.182 (talk) 08:50, 3 December 2009 (UTC)

src: pbs.twimg.com

Replay attack

The article gives an impression that digital signature stops replay attack. I don't think replay attacks can be stopped by signing messages. If I can observe and record a signed message sent by A to B, I can re-send the same message without B having any way of detecting the fraud.

There are other ways of preventing replay attacks. For example, the message needs to contain a timestamp or sequential number.

src: images-na.ssl-images-amazon.com

Digital signatures use encryption techniques, but are not used to encrypt

The current article mingles too much digital signatures and encryption. It might give the reader the impression that by digitally signing, the message also becomes encrypted. Though public key encryption is also used in encryption, the purpose of signing is not encryption. There are two reasons why private keys for digital signatures should not be used to encrypt.

• First quite often you might want something signed (digitally) but readable by everyone. E.g. diplomas, birth certificate, identity certificates, drivers license, the fact that you are the owner of something, etc... These should be in plain text but the digital signature is used to verify that they are not forged.

• Secondly, and much more important, the fact that you engage in an encrypted conversation does not mean that you want to sign all these messages in a legal sense. E.g. I might have an email conversation with a Rolls Royce dealer about buying a car, but this does not mean that I signed an electronic contract with that dealer. For that reason it is advised to use separate private keys for encryption and digitally signing. If a signed document needs to be encrypted, encryption is used on top of the signing.

Wintermute314 14:17, 13 May 2006 (UTC)

Agreed (now that I've finally noticed this comment). And I remeber that I'd noted this in my last major edit. I'll look again. ww 15:46, 27 July 2006 (UTC)

src: pbs.twimg.com

Clarification of the use of the word signature in the term 'digital signature'

Greetings Wikipedia Crypto editors.

First of all, I am not a crypto-anything. I'm simply trying to learn enough from these pages to give me a good working grasp of the technology, from a practical, everyday point of view. That said, may I suggest inclusion of the following section, probably somewhere near the top, which clears up an aspect of digital signatures that I was finding particularly confusing..

"In the context of pens and sheets of paper the term signature refers solely to the name of the document author scribbled at the bottom of the page. If his signature is to attest to the document's authenticity, the author must use the same signature each time he signs a document.

A digital signature, on the other hand, is the result of encrypting some digital information with a private key. Thus, a digital signature contains the information it is attesting to (in encrypted form) and will be different for each different set of information.

The last entence above is not necessarily so for some types of digital signature. Admittedly, not so useful a type, but... ww 15:50, 27 July 2006 (UTC)

Within the field of public key cryptography encrypting information with a private key is known as signing for one reason only; because use of the private key to encrypt the information, rather than the public key, facilitates the authentication of that information (as handwritten signatures do), rather than the establishment of confidentiality (as encrypting it with the recipient's public key would do).

Mostly, yes. ww 15:50, 27 July 2006 (UTC)

One further comparison exists; both handwriten signatures and digital signatures must accompany the (unencrypted) information they are intended to authenticate. Whereas a handwritten signature is compared with a securely held master copy, a digital signature is decrypted using the sender's public key, resulting in two copies of the same information, and the two copies are compared. If they match, the key used to encrypt the information is not in doubt and in that sense the information is authentic."

Sebyte 11:34, 18 May 2006 (UTC)

You've got more of it than most people do. Consider yourself a crypto cognocenti, for someone who's only intested in the practical side. ww 15:50, 27 July 2006 (UTC)

So just to be clear on this, verification of a signature involves decryption into plain-text, using the public key. Why is it so hard for people to say this? I read most of a book and half a dozen websites, and it still was not easy to determine that signing and verification is essentially the same as encryption & decryption, but just the other direction (private key to public key instead of public to private), but in both cases you can get back to plain-text. Nerfer (talk) 20:14, 3 December 2013 (UTC)

src: dz2cdn2.dzone.com

Remove history section?

The history section in this article is the same as in electronic signature. This is confusing. Since it is made clear that digital sigs are a special case of electronic sigs and there are already links to electronic signatures, I propose to delete the history section in this article. --Wintermute314 13:50, 11 June 2006 (UTC)

I think I'm the culprit. I left it in both articles as a way to head off some of the misconceptions so many acquire. WP being a didactic and informative medium, it's an obligation of editors to head off common confusions if possible. i agree that the duplication offends a sense of prsimony, mine included, but I assuaged mine with the observation that a reader who didn't do what I would prefer him/her to do (namely follow the links out, and weld the info found into a coherent whole) will be misled in a subtle way by omission. I've wrenched myself to a point of aggrieved acceptance. Perhaps it's an invitable result of an encyclopedia sort of format? ww 15:56, 27 July 2006 (UTC)

src: f4.bcbits.com

Why does Digital Signature have to only focus on PKI?

I understand that there is a large number of people that feel the same regarding electronic vs digital. I agree that an electronic signature does not mean that a cryptographic solution is present. However we also cannot assume that a PKI/Cryptographic solution is the ONLY way to capture a digital signature. It is merely ONE way out of many.

Agreed. It is only one of many, PKIs not being what the legal beagles had assumed they would become a decade ago when they began enacting and all. But it (or the general class, there are several crypto signature algorithms) is the only sort which can provide robust security if used correctly. PKI is not a useful distinction. ww 16:01, 27 July 2006 (UTC)

Wiki has a page for each topic and a read can drill down to get more specific information. Therefore Automobiles >> Cars >> Sports Cars would be similar to Electronic Sig >> Digital Sig >> PKI. The digital Signature page should discuss all topics relevant to Digital Signatures (like PKI, message authentication codes, file integrity hashes and digital pen pad devices) and then a reader could select the sub-page to learn more.

Readers cna indeed drill down. The Average Reader cannot be expected to do. See my comments (re Wintermute's observations) about an intent to be achieved in these two articles. ww 16:01, 27 July 2006 (UTC)

Making the dig sig page exclusively about PKI would be like only talking about 2-door cars without discussing all of the other options. If a reader wants to learn more about PKI then send them to PKI. Each page should discuss an overview of all the sub-pages:

It would indeed do so. My last major edit of these tried not to do so. I'll take a look to see if that remains. ww 16:01, 27 July 2006 (UTC)

1. Electronic Signatures
   1. FAX
   2. Morse Code
   3. Click Wrap
   4. Digital Signatures
      1. PKI
      2. Pen Pad

src: pbs.twimg.com

merge with Electronic Signatures

Digital signatures are a "subset" of electronic signatures. While there is confussion on the subject among some resources, major signture companies, Universities and the US Government define it as follows:

• "Just as digital signature technology is a subset of electronic signature technology, electronic signature technology is a subset of its own accord, this time, of electronic approval management technology."
• "Digital signatures, which are a subset of electronic signatures," Adobe
• "electronic signature technology of which digital signatures are a subset" University of Virginia
• "Electronic signatures and its subset, digital signatures" State of WI
• "Digital records are a subset of electronic records" National Archives of Australia
• "A subset of electronic signatures--digital signatures" CIO
• Just Google for 'digital subset electronic signature' (quotes not needed)

Additionally US Law Defines Electronic Signatures

• UETA (adopted by 48 states) - Definitions given in Section 2 do not include Digital Signatures
• Electronic Signatures in Global and National Commerce Act (newest US eSginature law) - Definitions given in sec 106 do not include Digital Signatures

Digital Signatures are those that include an image or graphic to represent the signature. They are electronic signatures but not all electronic signatures are digital. These two articles on Wiki have much of the same information but are separated. Isaacbowman 14:43, 4 May 2006 (UTC)

I would not merge digital and electronic signatures in one article. Although one is a subset of the other, the article would become too long, since there are many electronic signatures and digital signatures are so important that it merits a separate and also long explanation. Often users will search specifically for information on digital signatures because of legal requirements so we should make it easy for them and not have them dig it out of a larger and broader article.

I do agree that the shared (legal) info could be promoted to the higher level article of electronic signatures, and this article could link to that.

--Wintermute314 07:59, 30 May 2006 (UTC)

Not a complete merger but the information is very confussing to someone that doesn't know the difference. I felt that the pages should be 'cleaned' to reflect the difference. Isaacbowman 03:44, 27 July 2006 (UTC)

I would note that the confusion is inherent in the way that so many misuse words in such a way as to not match the underlying engineering, usually in mutually incompatible ways. The confusion does not exist if starting from the engineering possibilities (at least for the crypto stuff). And from an increasing degree of spoofability. Since the confusion needs must addressed some time, might as well start at the start. ww 16:11, 27 July 2006 (UTC)

src: i.ytimg.com

US ESIGN does NOT confuse electronic signature and digital signature

I have repeatedly corrected this confusing and incorrect statement, but another keeps putting it back in, as if their own confusion over the terms can be attributed to a perfectly fine law.

The (incorrect) language currently reads:

"The U.S. Electronic Signatures in Global and National Commerce Act of 2000 uses electronic signature when digital signature (in the sense used here) is meant, illustrating the confusion in legal usage."

However, this is not true as there is no confusion in the legal usage.

The US ESIGN Act correctly uses the legal term electronic signature every time. It never uses the term digital signature as it never discusses such technologies. Only a few old timers hold to the notion that these terms are interchangeable. Nearly everyone in the cryptographic and electronic signature communities understands digital signatures to refer to either the public/private key encryption+hashing technology, or at least some other reference to actual digital data that "enforces" the signing process that took place. There are digital signature standards and digital signature technologies, none of which by themselves are electronic signatures (which typically requires a process to show specific, willful intent and consent, disclosures, record generation and retention, proof that the data signed is original -- often done with digital signatures).

Electronic signatures clearly imply only the legal sense and is used correctly and consistently in the US ESIGN Act. The US ESIGN Act does not mandate particular technologies that accomplish the legal act, and in fact, allows for some "lower quality" consent signatures such as email exchanges that do not use any form of digital signature technology.

Other than those who hope to keep confusion in the marketplace with antiquated and no longer legally recognized language (digital signatures were not legalized; electronic signatures are, whether they use digital signature technologies or not), digital signatures refer to technologies and electronic signatures refer to a legal concept. This is well established in law, in the electronic signature marketplace and in the encryption community.

A more correct rendering of that statement, should it be needed at all since the US ESIGN Act makes zero references to digital signatures, would be:

"The U.S. Electronic Signatures in Global and National Commerce Act of 2000 uses the term electronic signature rather than digital signature to reflect the distinction between a legal concept and various technologies discussed below." --The preceding unsigned comment was added by 72.235.96.173 (talk) 20:12, 31 December 2006 (UTC).

The terms electronic signature and digital signature are in fact often confused. The edit history of the two articles demonstrates this amply, if support is required ofr the confused usages. It is important to distinguish between the two concepts, whatever the US Esign Act does or doesn't do. My own interpretation is that it is an incompetent piece of legislation, adopted as it was without discussion or debate of any kind under the impression it was some sort of 'technical help' to the computer and communication industry. It instructs courts to give credence to a variety of possible methods of signing documents electronically, a large subset of which include no credibility for the 'signature' attached. It does fit, more or less with a series of court holdings regarding signature validity which include presuming a signature to be valid that was never actually made. WP should not follow any legislation, however poorly drafted and accidentally enacted if it gets the concepts wrong. Simply becasue confused concepts have been included in legislation does not accord them validity worthy of being included here.

Consider the number of books collecting idiot laws from here or there which have been published. Vastly amusing, but not probative in the WP context.

Reactions? ww 20:33, 14 February 2007 (UTC)

src: pbs.twimg.com

Cause and effect

A recent edit changed "Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this is still considered to be computationally infeasible by most cryptographic hash functions (see colission resistance)." to "Furthermore, there is no efficient way to modify a message and its signature to produce a new message with a valid signature, because this would be a type of forgery.

I consider the revision incorrect, because whether or not an alteration is a type of forgery has nothing to do with whether or not there is an efficient way to modify a message and produce a valid signature. Indeed, it is because some digital signature schemes make it extremely inefficient to modify a message and produce a valid signature that those schemes are attractive.

Mangojuice provided this edit summary: "revise; signatures don't always involve hashes; when they do, hashes are just another type of integrity guarantee." I don't disagree with the edit summary, but if the text needs modification, we need to find a formulation that does not reverse cause and effect. --Gerry Ashton 17:47, 14 February 2007 (UTC)

I suspect what Mango was aiming at was something along the lines of "...would be detectable as a type of forgery." I agree with you that your interpretation of his edit suggests an unfortunate conclusion for some readers. Please change it. ww 20:37, 14 February 2007 (UTC)

The old text seems to imply that both (1) signature schemes are always used with hash functions, and (2) it's the hash function that provides the integrity property; both are false. In any case, we should probably rewrite that section because integrity is an implied sub-property of authentication anyway (and I'm not aware of any applications that use digital signature schemes when only integrity is sought: they'd just use a hash function or a checksum instead, much cheaper). Mangojuice^talk 02:54, 15 February 2007 (UTC)

How would you feel about replacing the integrity section with this?

While authentication shows that the signer wrote some message, it does not demonstrate that the message has not been accidentally or intentionally altered either during transmission, or while in the possession of the receiver. A digital signature scheme is more attractive if also provides integrity, that is, if any change in the message will be detectable at any time in the future. A common way to achieve this is to compute a cryptographic hash function, so that it will be computationally infeasible to modify a message and its signature to produce a new message with an apparently valid signature (see collision resistance).

--Gerry Ashton 18:07, 16 February 2007 (UTC)

src: i.ytimg.com

Digital signed email

Can someone please talk about the digital signed emails? Jackzhp 21:20, 27 April 2007 (UTC)

src: pbs.twimg.com

Vendors and products

This category is highly needed as people are looking for information where to obtain solutions. I have already tried to compile a list though someone removed it. --markush8 16:15, 15 May 2007 (CET)

It's advertising. Use internal links instead, e.g. VeriSign. Mangojuice^talk 14:24, 15 May 2007 (UTC)

Furthermore, wikipedia is not a directory (see WP:NOT#DIR). I.e., wikipedia does not want to replace the yellow pages and thus a list of vendors does not belong here. 85.2.106.93 17:01, 15 May 2007 (UTC)

Of course, wikipedia is not a directory though it should provide as much information to a certain entry as possible. If this done by using internal links to major vendors etc. I had to search a long time to find the leading vendors. Hence this page should also be a time saver and provide people with some pointers. --markush8 09:51, 16 May 2007 (CET)

There are better places to look for vendors than wikipedia. For example, searching through the list of exhibitors of recent RSA conferences might be a starting point. If you project requires FIPS validation, then going through the list of FIPS validated algorithms might be useful. I don't know what the requirements of your projects are, but I'm wondering why companies like RSA security or Certicom (and dozens of other companies) were missing in your list. Possibly, you were looking for a list of vendors with very specific products. However, other readers will have different requirements and hence looking for a different set of companies and products. Therefore your list of vendors was not only out of place but also is not very helpful. 85.2.78.229 11:36, 16 May 2007 (UTC)

Well then let's compile a list of major, leading vendors which provide overall solutions / products to the various areas of digital signature. --markush8 19:50, 20 May 2007 (CET)

If an authoritative list exists elsewhere on the web, it would be reasonable to link to it from here as an external link. Rhsatrhs 21:08, 20 May 2007 (UTC)

There are sister projects of wikipedia for that purpose, such as aboutUs.org. Adding a category for vendors of digital signature products would be more appropriate there. 84.73.231.90 06:10, 21 May 2007 (UTC)

Thanks for the pointer. I will try to create a list there and once ready we can link from here. --markush8 01:23, 22 May 2007 (CET)

Vendors are "advertising" all over the place here - so a list probably isn't necessary. Each one of these "information" pages is just a link to their page. Not bad, just advertising. Needs to be fairly applied - why some are there and not others? CIC, Orion,ARX, etc. are all in the same biz and all maintain refernce sites customers can use.---jkcmomma, Oct 31.208.180.123.195 15:52, 31 October 2007 (UTC)

Your comment reads like: "Other vendors get some advertisment from links to their web pages, so why can't I put my links there?". Wikipedia is not a forum for advertisments. If links do not contain useful information or if that information is clearly biased then the link should be removed. The links to ARX, Orion etc. indeed just show the companies point of view. They are borderline cases. Some people might find it somewhat helpful to the focus of some vendors. Personally, I prefer more unbiased sources. The link that you inserted, however, isn't even on the topic. There are some security related comments. It is not a source for information about digital signatures. Hence your link is a clear case of spam. 85.2.87.148 12:22, 2 November 2007 (UTC)

src: i.ytimg.com

Non-repudiation

The recent edit to this section reminds me of some points that might be made in this section, but I don't have sources:

• If cryptographically secure timestamps are used, and a key-holder can identify when a key was compromised, the key-holder can repudiate only those signatures that were signed after the compromise date.
• I understand that some CAs delete all expired keys from their database, no matter whether they merely expired, or if they were revoked. Thus, a person verifying a signature must assume all expired keys were compromised and revoked, since there is no way to verify that the key merely expired in the normal course of events. --Gerry Ashton 15:21, 6 July 2007 (UTC)

This shows the danger in even discussing non-repudiation techniques without context. Digital signatures alone or with a basic PKI are vulnerable to repudiation. Modifications to the model (such as, for instance, key revocation lists, or other techniques) can circumvent repudiation. Some standard techniques deserve coverage, and can be linked from here (eg Key revocation list). Note that non-repudiation isn't needed in all applications, particularly ones that use signatures ephemerally. More could probably go at Non-repudiation, though. Mangojuice^talk 17:12, 6 July 2007 (UTC)

A term we should avoid

Quoting from the above, the key-holder can repudiate only those signatures: I talked about this recently with a former private sector contracts lawyer whose current responsibilities with the Canadian federal government include interpreting statute and policy in this area. The lawyer's comment was basically that the quoted statement is flat out wrong: Any signature, ink-and-paper or electronic (secure, digital, whatever) can be repudiated. The issue is always whether the repudiation can be justified.

For example, put a gun to my head and I will quite happily enter my password and create a secure electronic signature authorizing you to do pretty much anything! Now, by Canadian law, I've just created a binding digital signature that identifies me as the signer and one that carries an evidentiary presumption under the Canada Evidence Act, a presumption that the signed electronic document is exactly what you claim it to be: An authentic authorization that somehow benefits you.

And of course I will repudiate it! And with the right evidence, I'll win. So I will have successfully repudiated something all of us technologists like to describe as non-repudiable.

Extreme example, I know, but carefully considering it and what that lawyer told me led me to eliminate the term non-repudiation from my vocabulary: It is pretty much useless to a lawyer or a judge, misleading for business executives and policy makers, and used only by technologists who are hoping to bring black-and-white to a grey area.

As far as I can tell from my research, the term "non-repudiation" was invented by technologists and has no legal meaning. I'd love to see statute examples to the contrary (quote me legs and regs and case law, in that order, and nothing else, 'cause those trump everything else when a judge speaks...).

End rant. I just get nervous when I see this term being used in an otherwise sophisticated discussion. --Preceding unsigned comment added by PeterWhittaker (talk o contribs) 17:40, 1 October 2008 (UTC)

Would you suggest some other term instead? --Gerry Ashton (talk) 17:50, 1 October 2008 (UTC)

I see nothing in your argument that is relevant to use of the words "repudiation" or "non-repudiation" in a technical context, and nothing in this article that uses those words outside of a technical context. To use an example from Wikipedia, something might well be wikt:notable without being WP:Notable; perhaps the choice of terminology is unfortunate, but trying to argue something is WP:Notable by using the definition of wikt:notable isn't going to get you anywhere. Anomie? 21:06, 1 October 2008 (UTC)

I don't know that I would suggest another term, I would avoid the concept altogether. If we consider "ink-and-paper" signatures, there is no such term, neither is there such a term in law. There is the concept of a signature and the linked concept of whether or not that signature is what it purports to be: Genuine and indicative of intent. Or, to put it another way, there are the questions of fact (was the signature made by the person whose signature it is claimed to be, was the signature made on this document) and the questions of judgement (were they lucid, did they know what they were signing, etc.). Only if the questions of fact are settled positively does judgement proceed, and it is in the question of judgement that the issue of repudiation is entertained.

In other words, in a technical context, there is no such thing as repudiation - repudiation is a legal concept. Likewise, in a technical context, there is no such thing as non-repudiation. And since there is no such as non-repudiation in a legal context, the term is actually useless.

In a technical context, we should stick to technical matters: What is the technology behind the digital signature (crypto) and what are the procedural and logical steps that can be taken to ensure that the signature being verified was made by a specific person? Obviously, the first part of that is fairly clear (the technology being understood and well studied) while the second part, like much of information security, is context-dependent (do we have a PKI and if so, do we have confidence in the CA; are we using PGP and if so who has signed the signer's key and has the signer released a self-revocation certificate; etc.). But in the end, the technical material is presented to establish a question of fact: Did X sign Y?

Note that time-stamping doesn't help, because it merely adds another fact to be determined, did T sign (X sign Y).

Since the question of repudiation arises only in a legal context, since the question of non-repudiation is not meaningful in a technical context, and since non-repudiation does not exist in a legal context, I would avoid both terms in a technical context and avoid non-repudiation in a legal context.

What term should we use? Sigh. I dunno. I'm sympathetic to the felt need for one, it would really be nice to have a term that catches what we mean ("in all likelihood, this digital signature was created by Alice, and it will tough for Alice to deny that") but I don't know that such a term exists, at least not in the technical context.

In one legal context, there is a useful term: Secure electronic signature, as defined in Canadian law. The law (legs and regs) indicates that the signature making process must be under the sole control of the person making the signature, the signature must be unique to the person and to the document being signed, the signature must identify the person, and the signature must be linked to the signed document in what we would consider the normal way (such that any change would invalidate the signature, etc.).

Having said that, I am not advocating propagating a term from a specific legal context as a general term in a technical context - I don't think that that is appropriate either. But perhaps that can be used to bridge the technical and legal portions of any discussions of digital signature: "What are these things good for? Well, in Canadian law, they can be used to create Secure electronic signatures, authentic electronic signatures considered legally binding and equivalent to "high value" signatures like notarized signatures or ministerial authorization". Only better written than that. :->

(It used to be that when I wrote policy in this area, I would write "and can be used in support of non-repudiation", as opposed to "provides non-repudiation". Now, I write "can be used in support of Secure Electronic Signatures", at least when working for a Canadian client. What would I write for someone else? I wouldn't know until I'd had a chance to talk with their counsel.)

If we really need a term to replace non-repudiation, I'd suggest the somewhat clumsy non-deniability, because that is closer to what we seek to establish in a technical context and because it aligns somewhat well with the legal context (as I understand it, IANAL, etc.): We seek to establish the fact that X signed Y, that X cannot deny having signed Y. For many business and administrative purposes, that will be sufficient. Then, in legal disputes, it will be up to X to argue the basis for their repudiating their signature, a signature they do not deny making.

But we would need to be as careful with any other term as I suggest we should be with non-repudiation: Establishing the matter of fact (that the signer made the signature and cannot deny doing so) isn't a simple process, since it depends on correct design and implementation of the technology, correct design and implementation of the application in which the technology is used, everyone playing by the rules (X not sharing their password, others signing only those keys/certificates they should, etc.).

We want a simple term, but the situation is not a simple one. Perhaps we will go wanting.

As for the notability comment, I either really don't understand it or totally agree with: Non-repudiation is notable mostly for being meaningless in both a legal context and a technical context, so why use it all?

PeterWhittaker (talk) 11:39, 2 October 2008 (UTC)

tl;dr. You still seem to be hung up on the legal definition of the term to the exclusion of the technical definition, which is unfortunate as the technical definition is what is in question here. The "notability comment" was an analogy. Anomie? 12:01, 2 October 2008 (UTC)

Call it a hang-up if you will, the fact is the technical definition, if any, is broken. For example, if you start at non-repudiation and follow the links to Non-Repudiation in the Digital Environment (Adrian McCullagh), there simply is no straight-forward, simple definition.

And it's arguable that even in the technical field, there never was a simple, straightforward definition. Warwick Ford devotes an entire chapter of Computer Communications Security to the concept, while Menzes, van Oorschot and Vanstone dedicate two pages of Handbook of Applied Cryptography to the subject (and in that book, two pages is a LOT!), and even that treatment comingles the legal and technical concepts.

It's a vague concept, one that bleeds from technology to law and back again.

As I noted elsewhere in this talk page, signatures are, ultimately, of interest to autograph hounds and those interesting in proving something. In its ultimate expression, "proving something" means presenting evidence and agreeing to the value of that evidence, before a court, if necessary. A digital signature is a remarkably valuable piece of evidence in such an exercise. But there is neither a technical nor legal thing that one can point to and say "Hey, we've established non-repudiation, whoo-hoo!".

We can establish cryptographic integrity, we can establish authenticity, we can establish probabilities that hashes or signatures were forged, given specific algorithms, key sizes, time frames, and computing power, we can establish that certificates were or were not issued to a specific person, but we cannot, at any time, either technically or legally, establish non-repudiation. It just don't exist.

There is fact: Did X sign Y? And there is judgement: Do we have grounds for believing that X intended to sign Y and be bound by Y, and, conversely, do we have grounds for believing for X was induced or coerced into signing Y and therefore permitting X to repudiate their signature?

There is already quite a good term for the technical fact "X signed Y": Authentic digital signature (as opposed to forged digital signature).

We don't need another technical term. The lawyers don't need us to invent a legal term. We're left with whether or not we need a "business executive" term, something short and punchy we can use to label what we mean, but something that won't get that executive into legal trouble when they make a business decision based on it. I don't know that we have such a need.

I'd argue that having such a term is potentially dangerous, because it permits us to slap on a simple label and avoid what is ultimately a messy and subtle area. As technologists, we want that label, 'cause we don't like messy. As business executives, ditto. But as those with a serious interest in information security, we have an obligation to discuss the subtle and the messy, especially when it has serious real-world implications, and to avoid short-cuts and jargon that add no value.

Is there value to the term "non-repudiation". I've argued there is not. I stand to be convinced otherwise (really!). But I've yet to see the argument, I've only seen inertia ("welllll, we have the term, let's not get rid of it, just in case"). --Preceding unsigned comment added by PeterWhittaker (talk o contribs) 13:06, 2 October 2008 (UTC)

PW, You object that a usage of a term in cryptographic contexts is at variance with legal usage (though the lawyers, courts, and legislators seem not to have settled on a particular view of digital signatures at all. More to the point, why should a legal interpretation of any term supersede (especially in technical use) its use in other fields? This is, I think, a reversal of the normal sequence in which new things are invented and only later come to the attention of courts and legislators and so to lawyers.

More generally, given the law's track record with the language, I'm loath to cede an standard making to it or those who follow it. More pseudo precision, and obscurity is not needed, though courts seem comfortable with both and seem encouraging. Law French or dog latin in English speaking contexts is mere surplusage. I wonder if mark Twain ever wrote on the topic; I feel sure his comments would have been sulphurous. ww (talk) 04:43, 15 October 2008 (UTC)

I'm with ww here. This is not about repudiation the legal term at all. If this discussion belongs anywhere, it belongs in the (poorly developed) Digital signatures and law page, which could probably use a lot more content. Mangojuice^talk 02:13, 16 October 2008 (UTC)

src: pbs.twimg.com

Drawbacks of digital signatures

I removed this section and it was restored. Here was my edit comment: time stamps can be prepended to the messages, non-repudiation is implied by unforgability, and WYSIWYS "problems" are independent of digital signatures

I'm not sure what more explanation is needed. If anyone disagrees with any of these explanations, please comment here. Skippydo (talk) 15:17, 14 October 2008 (UTC)

Digital signature algorithms are distinct from time stamp algorithms, so it is worthwhile to point out that digital signatures alone are unlikely to fully provide the protection required in a typical transaction. Similarly, digital signatures alone suffer from the electronic voting machine problem: how can one be sure what one sees on the screen is what is actually recorded as the final output of the process, unless one has 100% control over the machine applying the digital signature? --Gerry Ashton (talk) 15:54, 14 October 2008 (UTC)

I do not know what a time stamp algorithm is, I do not know what is required in a typical transaction. Please give me more detail.

If one does not have 100% control over the machine applying the digital signature, we are entering into the realm of grey-box attacks (eg side channel) and white-box attacks. I did not make the connection from the WYSIWYG section as it's currently written. Skippydo (talk) 16:49, 14 October 2008 (UTC)

The Trusted timestamping article discusses timestamping algorithms. Many transactions may need such a timestamp for two reasons:

1. A need for an independent indication of the time that a document was created or altered, because the signer or recipient of the document may be biased. This serves roughly the same purpose as a postmark on an envelope, or a date contained in a notary public's certificate.
2. In case a private key is compromised or expires, an ability to distinguish documents that were signed before the compromise/expiration from those that were signed after. --Gerry Ashton (talk) 17:18, 14 October 2008 (UTC)

Ahh, that makes sense. Do you happen to have any references on hand? Skippydo (talk) 19:39, 14 October 2008 (UTC)

I've seen this recent attack: http://www.mirlabs.org/jias/buccafurri.pdf Anybody think that it could considered in a section about Drawbacks of digital signatures or something like that? --Preceding unsigned comment added by 79.40.54.150 (talk) 08:05, 8 May 2010 (UTC)

src: 78.media.tumblr.com

DKIM

Update Needed. More about DKIM please.195.38.17.129 (talk) 13:38, 12 March 2009 (UTC)

Do you mean DomainKeys Identified Mail? If so, feel free to find a spot in the article to provide a link to that article. --Jc3s5h (talk) 13:52, 12 March 2009 (UTC)

Explanation and diagram

It seems to me this article misses completely the most important part at all: a simple explanation on how a digital signature is generated and attached to a document. Both Definition and History chapters explains a bit of the procedure, but both fails to do so properly. The first diagram is useful for understand the whole procedure, but, again, it is not explained enough: note a certificate is depicted there and the term is is not even mentioned in the text, let alone explained! I think this has to be fixed. Luca Mauri (talk) 15:03, 19 April 2009 (UTC)

The diagram is misleading. Signatures are not "attached" to documents. The word "attached" has no meaning in this context. A signature is generated using one of the algorithms, each is different. I do not know what certificate is meant to mean in this context. I believe the diagram should be replaced. Skippydo (talk) 21:19, 20 April 2009 (UTC)

Are you expert enough in the field to make one better? I am not, unfortunately.
Otherwise we could try to ask User:Acdx if he can fix it. --Luca Mauri (talk) 08:42, 26 April 2009 (UTC)

Yes, this is totally misleading. I was really confused about encrypting with private key and decrypting with public key.

hsidlagh (talk) 21:11, 20 August 2014 (UTC) -- Preceding unsigned comment added by 112.121.55.5 (talk)

Digital signatures in the Windows Operating System

Since the phrase "Digital Signature" is used by modern versions of the windows operating system, and indeed, the warning about software not having one is almost ubiquitous, there should be a section on how digital signatures are used to verify the publisher of software (as implemented in windows), or a link to an article focused on this topic. I came to this page looking for information on it (particularly, why almost no installers are signed), and while there's plenty of content that is relevant to people interested in cryptography and advanced security, there is nothing about the most visible (to a lay person) use of this technology. 38.113.0.254 (talk) 16:45, 7 January 2010 (UTC)

This would be an interesting, but complex topic. I am not qualified to write such an article, but I understand there are many varieties of digital certificate. Just in the freestanding software arena, there are signatures good enough for general applications, and a stricter standard for those that could affect the kernel in a way that could compromise digital rights management (which allows videos to be displayed on the screen but not copied). Then there are all the ways to sign extensions for Microsoft Office applications, plus all the other vendors who sell or give away extensible software that runs on Windows. --Jc3s5h (talk) 19:01, 7 January 2010 (UTC)

Incorrect terminology in diagram

The diagram (Digital_Signature_diagram.svg) is incorrect in that it suggests the private key encrypts the hash and the public key decrypts the hash. It is better to say that the private key signs the hash and the public key verifies the hash. If one must resort to referencing encryption/decryption, then the private key typically decrypts the hash and the public key encrypts it. This concept is even referenced in the main body of the page (in the History section). Duncan Jones (talk) 12:46, 25 July 2012 (UTC)

I think it would be best to clarify what happens in terms of encryption and decryption. Once we are sure we agree on that, we can discuss whether to use the words "encrypt" and "decrypt", or whether it is better to write "sign" and "verify". I checked Applied Cryptography (1994) by Bruce Schneier, pages 33-34 to confirm my understanding; to sign, the hash is encrypted with the private key and to verify, it is decrypted with the public key. This makes sense. Consider the situation of a verifier, Val. Val has access to the document, the signer's public key, and the encrypted hash. Val computes the hash independently, then decrypts the hash with the only key he has, the signer's public key. If the result matches the independently computed hash, the signature is verified.

Since the public key will be used for decryption, it follows that the private key must be used for encryption. Jc3s5h (talk) 13:14, 25 July 2012 (UTC)

I'm surprised Schneier uses such terminology. As Skippydo states, nearly all signatures schemes have no corresponding encryption schemes. Also, in the case of RSA, the process of signing with the private key is mathematically equivalent to the decryption operation. The text in the main body of the article also makes this point. In any case, it is misleading to refer to a signing operation as anything other than "signing". Duncan Jones (talk) 09:53, 26 July 2012 (UTC)

I've removed the diagram. encrypt the hash is a silly thing to say, since not every signature scheme corresponds to an encryption scheme. Skippydo (talk) 15:11, 25 July 2012 (UTC)

Skippydo, could you point out scheme that does not encrypt the hash? I suspect that phrase might not apply very well to DSA, but I don't remember that scheme very well. Jc3s5h (talk) 15:15, 25 July 2012 (UTC)

I'll reinterpretation your question as asking for a signature scheme without a corresponding encryption scheme. As you observe, DSA is an example of this. In fact, just about every signature scheme is an example, with the exception of the simple RSA-based encryption and identity-based encryption. Skippydo (talk) 15:25, 25 July 2012 (UTC)

Skippydo, the diagram was otherwise useful, can we not reinstate it with the offending words corrected? I'm afraid my Wiki-fu is weak and I'm not sure how to grab a copy of the old .svg to amend. Duncan Jones (talk) 10:55, 27 July 2012 (UTC)

Here it is. (The url is at the top of this section's source.) I'm not sure exactly what modification should be made. Perhaps trap door permutation could be used instead of encryption. Anyone care to comment? Skippydo (talk) 15:21, 27 July 2012 (UTC)

The diagram looks like it is describing the RSA signature scheme. In most other signature schemes the verification does not recover the hash from the signature. E.g. in DSA the hash of the message is needed to recompte r, which is then compared with the one from the signature. Hence it would make sense to state that the diagram shows RSA signatures and thus the operation in question could be described as modular exponentiation with private and public key. There are a few more improvements that would make sense: Currently the signing step can attach a certificate to the document, but the verification forgets to verify the certificate. If RSA is used as the example for this diagram then instead of comparing only the hashes one should compare the entire paddings to be sure that no attacks are possible. 178.195.225.28 (talk) 18:51, 27 July 2012 (UTC)

Inaccuracy in Digital signatures vs. ink on paper signatures

"... the digital signature on the last page will indicate tampering if any data on any of the pages have been altered, but this can also be achieved by signing with ink and numbering all pages of the contract." (emphasis added)

Numbering a physical contract's pages does not make them tamper-proof. It seems fairly obvious that this cannot be compared favorably with the cryptographic hash and signature of a digital document. -- Preceding unsigned comment added by Zombiedeity (talk o contribs) 06:21, 6 November 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Digital signature. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20141109180215/http://www.naa.gov.au/recordkeeping/er/Security/6-glossary.html to http://www.naa.gov.au/recordkeeping/er/Security/6-glossary.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers. --^{cyberbot II}_{Talk to my owner:Online} 16:02, 28 August 2015 (UTC)

Standards

The standards only states examples that are in my humble opinion irrelevant. Suggestion:

• Quote NIST DSS for the USA
• Quote XAdES, PAdES, CAdES an relate it to eIDAS in the EU

Any comment / agreement / disagreement? ScienceGuard (talk) 22:11, 1 March 2016 (UTC)

It is not clear what section of the article you would like to change, or what changes you would like to make.

Just because certain standards might have originated in certain country does not mean they are in widespread use in those countries. Indeed, I would say that DSS has minimal use in the USA. Jc3s5h (talk) 12:30, 2 March 2016 (UTC)

Clarification for those who are not math experts

In the Definition section, the following is shown:

on input 1ⁿ, where n is the security parameter

I assume that "1ⁿ" does not mean "one to the power n", since that would be silly. Perhaps someone should clarify what it means in the article, so those without the math background will understand. 99.246.86.48 (talk) 16:55, 1 September 2016 (UTC)

Added reference to unary number system. 99.244.233.91 (talk) 19:16, 5 November 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Digital signature. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20060925104000/http://enterprise.state.wi.us/home/strategic/esig.htm to http://enterprise.state.wi.us/home/strategic/esig.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

You may set the |checked=, on this template, to true or failed to let other editors know you reviewed the change. If you find any errors, please use the tools below to fix them or call an editor by setting |needhelp= to your help request.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

If you are unable to use these tools, you may set |needhelp=<your help request> on this template to request help from an experienced user. Please include details about your problem, to help other editors.

Cheers.--InternetArchiveBot (Report bug) 17:07, 10 September 2017 (UTC)

Source of the article : Wikipedia