Talk:Forward secrecy

Comment about signal messaging app

It should probably be mentioned that the signal messaging app employs a form of forward secrecy. — Preceding unsigned comment added by 128.187.48.247 (talk) 16:45, 17 April 2018 (UTC)

Done. Thanks for the suggestion. Steevven1 ^{(Talk) (Contribs) (Gallery)} 17:29, 18 April 2018 (UTC)

@Steevven1 103.166.152.39 (talk) 21:18, 23 August 2023 (UTC)

Reply 103.166.152.39 154.80.51.56 (talk) 14:03, 4 October 2023 (UTC)

Comment of 28 April 2006

User:Bassistphysicist added the claim "The current hope for perfect forward secrecy is hyper-encryption." I'm not an expert on this issue, but it seems to me that re-negotiating the session keys every once in a while (as in Off-the-record messaging) does already satisfy properties of 'perfect forward secrecy', so we don't need "hope" - it's already here. Thus, I decided to revert the edit for now. -- intgr 22:08, 28 April 2006 (UTC)

I think re-negotiating keys "once in a while" can not be the base of perfect forward secrecy. So, let's say, we re-negotiate once in 10 seconds. We use a connection for one second, then stop using it, and completely loose control over the connection at this point, and know, for the example, an adversary is able to fully control the connection including both end points from now. Now, should I worry about what the adversary can do during the next nine seconds - that is, gain information about the data transfered in the previous second? At least, I'm positive that in this kind on algorithm "once in a while" does not work, fundamentally. Volker Siegel (talk) 04:39, 9 March 2014 (UTC)

How does this definition match towards A. Perrigs definitions given e.g. here: http://www.ece.cmu.edu/~adrian/projects/sec/node6.html Is the forwards secrecy here the same as backward secrecy there and ist PFS here the same as forward secrecy there? His naming is more intuitive...84.75.118.97 08:32, 30 September 2007 (UTC)

Broken Link

Broken link: reference [2] —Preceding unsigned comment added by 195.176.178.209 (talk) 06:33, 9 June 2009 (UTC)

The proper links seem to be http://atis.org/glossary/definition.aspx?id=3185 and http://atis.org/glossary/definition.aspx?id=5189. –134.60.1.151 (talk) 13:14, 25 November 2010 (UTC)

appears completely random

Why "appears" ?? An OTP REQUIRES that random data is used. Even the word "completely" is superfluous as there is no incomplete randomness. If something is not "completely" random it is NOT random. So in my opinion instead of "appears completely random" it should be "is random". Sorry, but our societys language seems to be more influenced by advetising bla bla than by scientific accuracy. JB --92.195.72.160 (talk) 14:16, 9 April 2014 (UTC)

It's talking about the ciphertext -- the output of OTP after encryption. There is information encoded in the ciphertext, but it nevertheless looks random. I think "appears" is appropriate given that, but I don't feel strongly either way. -- intgr [talk] 18:21, 9 April 2014 (UTC)

Timeless History

The history section doesn't contain any dates. — Preceding unsigned comment added by 204.119.134.123 (talk) 16:40, 22 May 2014 (UTC)

Attacks ?

This whole section looks like WP:NOR to me... --Webwizard (talk) 19:48, 2 July 2014 (UTC)

Tag it with {{original research|section}} if you like. davidwr/(talk)/(contribs) 01:26, 6 July 2014 (UTC)

Perfect Forward Secrecy

This section uses three different terms: message, session and conversation. I think they're all supposed to be the equivalent, but it is ambiguous as it stands. I would also suggest not using "message". Communication protocols and encryption are not my forte, but I would think that a session consists of multiple messages. I would also think that if a message is compromised, then the rest of the messages in the session are compromised. I think forward secrecy is about different session and conversations, where a key from one session/conversation cannot be used to decode any other sessions/conversations. I do realize that when communication protocols are discussed in the abstract, "message" is sometimes used to describe protocols at a high level. I think, however, with the use of more technical terms, or at least other terms, it becomes ambiguous.

I know "perfect forward secrecy" is a term that is floating around, but I've noticed that it is more recently referred to as just "forward secrecy", to avoid "perfect" (one has to be careful with "perfect" when it comes to encryption), and to avoid confusion with the term "perfect secrecy".

Just my thoughts. FreeText (talk) 16:21, 21 August 2014 (UTC)

That makes me wonder, "What is imperfect forward security? Jimw338 (talk) 15:03, 27 June 2018 (UTC)

Description of Forward Secrecy is Ambiguous

I'm curious, does anyone find the description of FS ambiguous?

""In cryptography, forward secrecy (abbreviation: FS, also known as perfect forward secrecy or PFS[1]) is a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future. The key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys. In this way, compromise of a single key permits access only to data protected by that single key.""

I think the use of the word "derived" is too abstract and meaningless. In what sense is a session key derived from a set of long-term keys? The problem is long-term keys (i.e., the public keys which appear in a site's X.509 certificate) are used to confidentially transmit the session key (for use with a symmetric cipher) from the client to the server. So, if a secret key belonging to any one of the public keys is ever compromised, the confidentiality of older, captured sessions is compromised. The solution is to use ephemeral keypairs for session key exchange.

Thoughts?

Kmddmk (talk) 19:52, 6 December 2014 (UTC)

Hmmmm.... I've perhaps let this article's lede stand uncorrected for too long. Anonymous Diffie-Helman providers FS without ANY prior long term keys, so the first sentence of the article is flat-out incorrect (though it does describe a common case). I'd welcome further input before wading in a changing this... Ross Fraser (talk)

No one has stepped forward on this issue since it was raised a year ago. The definition used in the lede is problematic for many reasons:
1) it has no citations
2) it is incorrect, insofar as Anonymous Diffie-Helman provides FS without ANY prior long-term keys and hence the sentence "ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future" doesn't apply in every case
3) it doesn't mention FS's most important functional characteristic which is that a recording of today's encrypted session can't be decrypted in the future even if a private key of one of the communicating parties is subsequently compromised. This is what the reader will most likely find interesting and useful.
4) the sentence "In this way, compromise of a single key permits access only to data protected by that single key" applies even to plain (non-FS) RSA: compromise of my private RSA key permits access only to data protected by that single key". This text may confuse readers who will miss the subtleties of symmetric session keys and their use with long-term public/private keys.

I've gone back to the text of "Handbook of Applied Cryptography" (an acknowledged classic) and other sources to obtain text of a good and clear definition. Ross Fraser (talk) 02:56, 16 October 2015 (UTC)

Forward secrecy vs key erasure

@Tarcieri: You have introduced the term "key erasure" to this article in two recent sets of edits. However, the whole industry is using "forward secrecy" for this purpose. This seems to be DJB's own personal pet peeve.

Most hits on Google for "key erasure" talk about wiping keys, not about establishing new independent keys per each session. The hits that are relevant, seem to be primary sources published by DJB himself. I believe this should be treated as a fringe position, and the bold mention in lead section gives it undue weight. Unless you can demonstrate that "key erasure" is established in cryptography literature, e.g., textbooks and other essential resources using the term.

If you're trying to popularize new terminology, however much you may believe that it's better, Wikipedia is not the place to do it.

PS: You can also ping me in ##crypto -- intgr [talk] 14:09, 8 April 2015 (UTC)

Agreed. Key erasure is not a common term of art. Ross Fraser (talk) 02:11, 19 April 2015 (UTC)

No one has commented since April 2015, so I've removed this section. The cited reference nowhere criticizes the use of the term "forward security" or "perfect forwrd security". Key erasure just isn't in common parlance and only adds to the confusion re: perfect FS vs. FS. Ross Fraser (talk) 02:12, 16 October 2015 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Forward secrecy. 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/20130629200207/http://blogs.computerworld.com/encryption/22366/can-nsa-see-through-encrypted-web-pages-maybe-so to http://blogs.computerworld.com/encryption/22366/can-nsa-see-through-encrypted-web-pages-maybe-so

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

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• 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.

Cheers.—InternetArchiveBot (Report bug) 11:14, 20 January 2018 (UTC)

"Description" Section?

I came to this page seeking a basic understanding of forward secrecy and ended up needing to seek help elsewhere. Perhaps a "Description" section could be added to give a practical "Alice and Bob"-style example of exactly how forward secrecy is implemented and what it means? I'd like to make edits myself, but I am not confident enough in my knowledge to do so.

In a typical forward secrecy messaging setup, are asymmetric public and private keys used ONLY for signing messages and authentication during key exchange, and NOT for encrypting messages or encrypting keys during exchange? And then a key exchange algorithm like Diffie-Hellman is used in the clear to create a new "session key" for each message, to be used with symmetric ciphers? Steevven1 ^{(Talk) (Contribs) (Gallery)} 01:40, 22 February 2018 (UTC)

After some research, I attempted to address my concerns myself, just now. Could someone check over my work and cite some sources where possible, especially in the "Example" section? Thanks! Steevven1 ^{(Talk) (Contribs) (Gallery)} 15:14, 22 February 2018 (UTC)

Inherently client/server?

Why does the first sentence mention a server? Especially given the Alice/Bob example later, there doesn't seem to be anything inherently client/server-related about the concept, at least nothing that deserves mention in the opening sentence.

I'm hesitant to reword it myself as I'm not an expert, so don't have a confident suggestion of what to reword to.

Gfredericks756 (talk) 12:03, 13 August 2018 (UTC)

I agree with that sentiment, forward secrecy is not inherently client/server. Markulf (talk) 10:49, 23 July 2020 (UTC)

Inaccuracies in definition of forward secrecy, long-term vs session key compromise

As pointed out earlier, the requirement for independent session keys is important, but is different from the requirement for forward secrecy.

"By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key."

This property can also be achieved by RSA key transfer, which encrypts a unique session key with a long-term RSA public key. Compromise of the session key only affects the specific session, but compromise of the RSA secret key affects past sessions and thus compromises forward secrecy.

See also point 4 of Ross Fraser above:

'4) the sentence "In this way, compromise of a single key permits access only to data protected by that single key" applies even to plain (non-FS) RSA: compromise of my private RSA key permits access only to data protected by that single key". This text may confuse readers who will miss the subtleties of symmetric session keys and their use with long-term public/private keys.'

I suggest a rewrite that distinguishes forward secrecy from session key compromise. Forward secrecy is about long-term key compromise. Markulf (talk) 10:49, 23 July 2020 (UTC)

Value of forward secrecy

'The value of forward secrecy depends on the assumed capabilities of an adversary. Forward secrecy has value if an adversary is assumed to be able to obtain secret keys from a device (READ access) but not modify the way keys are generated in a device (WRITE access). In some cases an adversary who can read keys from a device may also be able to modify the functioning of the session key generator. In these cases forward secrecy has no value.'

There is a connection between the discussion above and forward secrecy, but this feature might be better captured by the notion of post-compromise security. https://eprint.iacr.org/2016/221.pdf. I suggest a reference to this related concept once a page is created.

Even if an attacker gains WRITE access to a device, there is still value in forward secrecy, as past sessions are still protected.

Markulf (talk) 11:36, 23 July 2020 (UTC)

@0509386905 5.194.79.145 (talk) 00:31, 28 November 2023 (UTC)

PRT10KCBR36BD5 114.125.31.64 (talk) 05:31, 30 January 2024 (UTC)