Talk:Non-repudiation

message: We really need a better word for this concept.
Although the use non-repudiation is widespread in the literature it is remarkably awkward and hard to use.  By itself non-repudiation is a noun but what we often want is an adjective.  Following usual English practice for turning a noun into an adjective we get non-repudiate-ability which is about as awkward and unpronounceable as it could be.
I would be thankful for something that wouldn't make the listener grimace.  — Preceding unsigned comment added by Hkc30 (talk • contribs) 04:56, 26 January 2021 (UTC)
thread_title:  Grammatical Awkwardness 

message: Without citing sources for now, I'll mention that there's a recognized use for repudiation (and therefore repudiability) in computer systems: the need to repudiate buggy or insecure code once a superior version has been introduced. This means both non-repudiability and repudiability are potentially valuable in the same machine.
A corollary here is that the repudiation of an inferior code object must itself be non-repudiable so that a bad actor can't induce a system to resume using code that has known vulnerabilities. This introduces the concept of irreversibility (used here in a different sense than the "reversibility" of most bulk/two-way cryptographic algorithms). Once a system is informed that a code object has been repudiated, it should be impractical to make the system forget that it has been so informed.
A new section addressing these points would be useful, but I don't have the time or the domain knowledge to do justice to it. 2603:3024:182A:6200:5C95:966F:647:F4B5 (talk) 21:58, 6 August 2018 (UTC)
replies: text: You're talking about support for updating broken code, which should not be confused with repudiation. Repudiation is also distinct from the sort of rollback attack you note. See a range of related topics at https://theupdateframework.io/overview/  Repudiation would be demonstrating that you didn't create some bad code which has been tied to your name, but distributed maliciously by someone else. To protect users, the code should come with non-repudiable evidence of who provided the code, e.g. via digital signatures combined with good identity proofing, software bill-of-materials, and the like. That way honorable providers can build a good reputation, and malware distributors will have a harder time. ★NealMcB★ (talk) 21:05, 31 October 2022 (UTC)
thread_title:  Repudiation as a desirable feature 

message: Generally, MACs are not said to provide non-repudiation. See e.g. 
* Message_authentication_code#Security: "For the same reason, MACs do not provide the property of non-repudiation offered by signatures specifically in the case of a network-wide shared secret key: any user who can verify a MAC is also capable of generating MACs for other messages."
* https://crypto.stackexchange.com/questions/66225/message-authentication-vs-entity-authentication
This article says otherwise: Non-repudiation#In_digital_security: "Common methods to provide non-repudiation in the context of digital communications or storage are Message Authentication Codes (MAC), useful when the communicating parties have arranged to use a shared secret that they both possess, [...]"
Mebuege (talk) 18:56, 19 September 2020 (UTC)
thread_title:  Non-repudiation and MACs