Change:
This has been reported unclear multiple times. I strongly prefer forbidding reuse altogether. A validation mechanism is needed for the formal security proof, it can be implemented according to an expiration mechanism (see Architecture - 4.2. Delivery Service Compromise)
We need to allow Last Resort keys. Not sure what you mean by "replay attacks"
I rewrote it in favor of using "SHOULD NOT reuse", which is true, except in case of last resort to avoid DOS, which we are willing to allow. Normal meaning... If I remember correctly, there is a cross channel forwarding attack (replay) possible on the first message in Signal when reusing prekeys (the last resort key) because it lacks some channel binding but I would have to check. I am working to make sure we don't suffer the same defect but I am documenting it in the mean time.
I can live with this for now; we can refine later.
Here's the Weekly Digest for : - - Last week 9 issues were created. Of these, 6 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 2 comments. - - Last week, 13 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 10 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 38 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .*
Here's the Weekly Digest for : - - Last week, no issues were created. - - Last week, 5 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .

Discussion:
supports, as well as providing a public key that others can use for key agreement.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change <del> it.  Init keys are intended to be used a very limited number of times, ideally only once.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites, or to reduce the likelihood of init key reuse. ClientInitKeys contain an identifier chosen by the client, which the client MUST ensure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. </del> <ins> it.  Init keys are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See init-key-reuse).  Clients MAY generate and publish multiple ClientInitKey objects to support multiple ciphersuites.  ClientInitKeys contain an identifier chosen by the client, which the client MUST ensure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. </ins> The value for init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is

13.4. Initialization keys are intended to be used only once and then <del> deleted.  Reuse of init keys is not believed to be inherently insecure dhreuse, although it can complicate protocol analyses. </del> <ins> deleted.  Reuse of init keys can lead to replay attacks. </ins> 14.