)]}'
{"id":"openvpn~806","triplet_id":"openvpn~master~I00751c42cb04e30205ba8e6584530831e0d143c5","project":"openvpn","branch":"master","topic":"epoch","attention_set":{},"removed_from_attention_set":{"1000003":{"account":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"last_update":"2025-02-12 18:02:57.000000000","reason":"Change was submitted"},"1000002":{"account":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"last_update":"2025-02-09 15:27:21.000000000","reason":"\u003cGERRIT_ACCOUNT_1000002\u003e replied on the change","reason_account":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"}},"1000001":{"account":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"last_update":"2025-02-12 18:02:57.000000000","reason":"Change was submitted"},"1000030":{"account":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"last_update":"2025-02-12 16:11:24.000000000","reason":"\u003cGERRIT_ACCOUNT_1000030\u003e replied on the change","reason_account":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"}}},"hashtags":[],"change_id":"I00751c42cb04e30205ba8e6584530831e0d143c5","subject":"Implement epoch key data format","status":"MERGED","created":"2024-11-11 01:59:03.000000000","updated":"2025-02-12 18:02:57.000000000","submitted":"2025-02-12 18:02:57.000000000","submitter":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"total_comment_count":19,"unresolved_comment_count":0,"has_review_started":true,"submission_id":"806-epoch","meta_rev_id":"6741fff70bcd468f4eefe26d3ac5dddcdb2f3431","_number":806,"virtual_id_number":806,"owner":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"actions":{},"labels":{"Code-Review":{"all":[{"value":0,"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"value":0,"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"}],"values":{"-2":"This shall not be submitted","-1":"I would prefer this is not submitted as is"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me, approved"},"description":"","default_value":0}},"removable_reviewers":[{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."}],"reviewers":{"REVIEWER":[{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"}],"CC":[{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2024-11-11 01:59:10.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000026,"name":"openvpn-devel","email":"openvpn-devel@lists.sourceforge.net","username":"openvpn-devel"},"state":"CC"},{"updated":"2024-11-11 01:59:10.000000000","updated_by":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"reviewer":{"_account_id":1000001,"name":"flichtenheld","display_name":"Frank Lichtenheld","email":"frank@lichtenheld.com","username":"flichtenheld","status":"OpenVPN Inc."},"state":"REVIEWER"},{"updated":"2025-01-10 08:08:59.000000000","updated_by":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"CC"},{"updated":"2025-02-03 15:40:48.000000000","updated_by":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"reviewer":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"state":"REVIEWER"},{"updated":"2025-02-05 17:01:22.000000000","updated_by":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"reviewer":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"state":"CC"},{"updated":"2025-02-12 16:11:24.000000000","updated_by":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"reviewer":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"state":"REVIEWER"}],"messages":[{"id":"8551fcae84a19f2ca58ecda282dfd66423f93f52","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-11 01:59:03.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"3d86b0ecfcc752e89a20b549ec9272b849d2ef9e","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-11 16:41:31.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"49b62b7bbf94dac1881405212621c8cb5b01cc13","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-14 13:45:07.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"0cf90263269d1d9b242f7778125674c8899bfdc5","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-15 15:12:22.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"f5e6660ef6c861ed704759c2f63bc875e71e38bd","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-22 16:29:15.000000000","message":"Uploaded patch set 5.","accounts_in_message":[],"_revision_number":5},{"id":"146d68c0c09577b6be3dec07e27781ae66eb6efb","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-11-30 13:38:17.000000000","message":"Uploaded patch set 6: Patch Set 5 was rebased.","accounts_in_message":[],"_revision_number":6},{"id":"f3f1e4d4c1b792deeadad9d502f4f0e5af130b24","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-01 13:53:49.000000000","message":"Uploaded patch set 7: Patch Set 6 was rebased.","accounts_in_message":[],"_revision_number":7},{"id":"cb570512cde499ad4006a234091ae14e820f81f8","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-20 14:49:42.000000000","message":"Uploaded patch set 8.","accounts_in_message":[],"_revision_number":8},{"id":"bc61b9d06d3ba6dfef99f79fefd59ad161b542f8","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-27 18:19:18.000000000","message":"Uploaded patch set 9: Patch Set 8 was rebased.","accounts_in_message":[],"_revision_number":9},{"id":"24f780957108b93cb558bb17dc229111426bd4c7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2024-12-29 03:12:52.000000000","message":"Uploaded patch set 10.","accounts_in_message":[],"_revision_number":10},{"id":"bca13db522dd7cba839ee09da8da86accacf5e88","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-04 22:51:55.000000000","message":"Uploaded patch set 11.","accounts_in_message":[],"_revision_number":11},{"id":"a035b49557cd3ca6f9313080dafc0c85f23b05d7","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-04 22:52:19.000000000","message":"Uploaded patch set 12: Patch Set 11 was rebased.","accounts_in_message":[],"_revision_number":12},{"id":"12d81c817634cc1b76e6f4bcb9a94abbf4ba5982","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-01-10 08:08:59.000000000","message":"Patch Set 12:\n\n(4 comments)","accounts_in_message":[],"_revision_number":12},{"id":"bc96346f78a7a3b10fe3c5f83f07368612321045","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-10 09:49:02.000000000","message":"Patch Set 12:\n\n(3 comments)","accounts_in_message":[],"_revision_number":12},{"id":"c1b2ebe2aec3e6a1d2214bddd505f23731a42e10","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-10 09:49:11.000000000","message":"Uploaded patch set 13.","accounts_in_message":[],"_revision_number":13},{"id":"2193542e9e1bfcdc151ab2979e199a9c63a2c4f2","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-13 12:09:40.000000000","message":"Uploaded patch set 14.","accounts_in_message":[],"_revision_number":14},{"id":"f374955ebcb23236ac7894a55c5f4cb549052009","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-13 12:14:28.000000000","message":"Uploaded patch set 15.","accounts_in_message":[],"_revision_number":15},{"id":"6702391125c763d6db41a9b4b182c80fe1000d1a","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-01-16 11:34:05.000000000","message":"Uploaded patch set 16: Patch Set 15 was rebased.","accounts_in_message":[],"_revision_number":16},{"id":"313dbfac16e96bcdf856bb820872ece5b775bc6f","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-03 15:40:48.000000000","message":"Patch Set 16: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":16},{"id":"f329c4559f6f0bb98ecbb53a24bb05fb52d6c660","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-03 18:19:12.000000000","message":"Uploaded patch set 17.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":17},{"id":"bff47481f37879f527c5024873efbf16240b2510","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 08:32:41.000000000","message":"Patch Set 17: Code-Review-2\n\n(1 comment)","accounts_in_message":[],"_revision_number":17},{"id":"e1df62e43d64f55156c286cf2e7e87dea19d92c3","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-04 08:45:03.000000000","message":"Uploaded patch set 18.\n\nCopied Votes:\n* Code-Review-2 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR **is:MIN**\")\n","accounts_in_message":[],"_revision_number":18},{"id":"68c46db42af9a0d86b00e404639e043987895560","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 10:56:34.000000000","message":"Patch Set 18: Code-Review-2\n\n(2 comments)","accounts_in_message":[],"_revision_number":18},{"id":"113338a4918fca394476f87b368ac42693244df4","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-04 10:57:01.000000000","message":"Patch Set 18: Code-Review+1","accounts_in_message":[],"_revision_number":18},{"id":"64140210568e6b9f564873c937266cbe6b1fd19c","author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"date":"2025-02-05 17:01:22.000000000","message":"Patch Set 18:\n\n(3 comments)","accounts_in_message":[],"_revision_number":18},{"id":"76aa699f790f589d88d5ba994b2dfa139e0098c6","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-05 17:07:25.000000000","message":"Patch Set 18:\n\n(2 comments)","accounts_in_message":[],"_revision_number":18},{"id":"cafb0255a708f18f23ac660e014c75ce42385051","tag":"autogenerated:gerrit:newPatchSet","author":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"date":"2025-02-07 13:00:06.000000000","message":"Uploaded patch set 19.\n\nOutdated Votes:\n* Code-Review+1 (copy condition: \"changekind:NO_CHANGE OR changekind:TRIVIAL_REBASE OR is:MIN\")\n","accounts_in_message":[],"_revision_number":19},{"id":"b5425082df8feebc996428b2f5f63a8eb5a8a198","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-09 15:27:21.000000000","message":"Patch Set 19: Code-Review+1\n\n(1 comment)","accounts_in_message":[],"_revision_number":19},{"id":"55a954a867fa00f81b02f908bb53c54385177142","author":{"_account_id":1000030,"name":"MaxF","email":"max@max-fillinger.net","username":"MaxF"},"date":"2025-02-12 16:11:24.000000000","message":"Patch Set 19: Code-Review+2\n\n(2 comments)","accounts_in_message":[],"_revision_number":19},{"id":"6741fff70bcd468f4eefe26d3ac5dddcdb2f3431","tag":"autogenerated:gerrit:merged","author":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"date":"2025-02-12 18:02:57.000000000","message":"Change has been successfully pushed.","accounts_in_message":[],"_revision_number":20}],"current_revision_number":20,"current_revision":"9f4670fc718a8c16280d60c3e2d4ad29cffa04c4","revisions":{"c728823e14163bec77e267694a36412571afc543":{"kind":"REWORK","_number":1,"created":"2024-11-11 01:59:03.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/1","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/1","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/1","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/1 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"8d85203f621a2c04e66ef3a5dc2cd2ad46c21565","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 01:50:58.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"cc7cc7a0c7080c8b720276be50c24e1697dceade":{"kind":"REWORK","_number":2,"created":"2024-11-11 16:41:31.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/2","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/2","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/2","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/2 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"7318a7bf32b67b4ab6c50f272b8fbc5f4b342fdb","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-11 16:41:25.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"a791cfd1b161e32cbf022775f3b15bdd23d6579e":{"kind":"REWORK","_number":3,"created":"2024-11-14 13:45:07.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/3","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/3","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/3","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/3 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"495cc12515ce2eadd0a92daf5b34df061320fa5c","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-14 13:44:53.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"88a133bf7f33bf10d245193dff1fb8cde581cf06":{"kind":"REWORK","_number":4,"created":"2024-11-15 15:12:22.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/4","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/4","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/4","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/4 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5487ed2dedca01c0e579541b15126552d9022d09","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-15 15:12:05.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"86c5d9a765c8bc4f7483f5da717454d96f7c33ab":{"kind":"REWORK","_number":5,"created":"2024-11-22 16:29:15.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/5","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/5","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/5","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/5 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3e8c2060cf5103a56e8072942789c2dad0bade76","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-22 16:29:06.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"f2b39e7de7d04a3d921058cbb3fc4171c9d07fce":{"kind":"TRIVIAL_REBASE","_number":6,"created":"2024-11-30 13:38:17.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/6","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/6","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/6","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/6 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"8409d04b5c9b8f4d9a40534371e1a4e3db8b24c8","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-11-30 13:38:01.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"6fd2541b5cc5a7be53d39cde0a6bcd5e6f516bdb":{"kind":"TRIVIAL_REBASE","_number":7,"created":"2024-12-01 13:53:49.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/7","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/7","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/7","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/7 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"d62dab40e58cf804253c5895cccdd0eff9eb1203","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-01 13:47:59.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"fe530222cd75152ee61e43f9caae2245a00ffe93":{"kind":"REWORK","_number":8,"created":"2024-12-20 14:49:42.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/8","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/8","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/8","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/8 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"98159607df3ebf41fb2294180751894f1c8a8427","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-20 14:38:06.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"21d97793733bfc629668f113cf93ba3cd9cda5c5":{"kind":"TRIVIAL_REBASE","_number":9,"created":"2024-12-27 18:19:18.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/9","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/9","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/9","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/9 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"4d6c0f48b81102de804f7ac4ed57c8b84ffbba29","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-27 18:18:49.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"bc3044082fd7e30c46424b20fd7b22d85375e9b3":{"kind":"REWORK","_number":10,"created":"2024-12-29 03:12:52.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/10","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/10","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/10","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/10 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"71f5c30729ae1741ed6e91302301252a3266f9f8","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-12-29 03:11:41.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"0b56780729f22a5914449981ab28fcc68f1e0867":{"kind":"REWORK","_number":11,"created":"2025-01-04 22:51:55.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/11","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/11","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/11","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/11 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"4e9f618b9bd9f87ebd4d1812d35a2d00896626ef","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-04 22:47:58.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"28d8b5ee153d9a8acaed01e085a2a393b5d7e29f":{"kind":"TRIVIAL_REBASE","_number":12,"created":"2025-01-04 22:52:19.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/12","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/12","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/12","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/12 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"cef11f0ea7df5ecf91c8100f4aab938d1ad2765b","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-04 22:52:08.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"2280c3317905e09d20317418575b2e3cfb85d921":{"kind":"REWORK","_number":13,"created":"2025-01-10 09:49:11.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/13","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/13","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/13","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/13 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"0671a4d009ae89870b645d1a8f3078d9943d5010","subject":"Rename aead-tag-at-end to aead-epoch"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-10 09:49:05.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"adc54228ba88bf134c8100ee3030bfd9c5644350":{"kind":"REWORK","_number":14,"created":"2025-01-13 12:09:40.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/14","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/14","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/14","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/14 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5e086c08f2ce4428fd014b74441f0197a71d6da8","subject":"Fix \u0027uninitialized pointer read\u0027 in openvpn_decrypt_aead"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-13 12:09:33.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"607dcaa0a5566aacba01baaed831c421761c2ded":{"kind":"REWORK","_number":15,"created":"2025-01-13 12:14:28.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/15","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/15","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/15","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/15 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"5e086c08f2ce4428fd014b74441f0197a71d6da8","subject":"Fix \u0027uninitialized pointer read\u0027 in openvpn_decrypt_aead"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-13 12:14:15.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"55972246ccba388d16de72c4950dc319a59de980":{"kind":"TRIVIAL_REBASE","_number":16,"created":"2025-01-16 11:34:05.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/16","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/16","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/16","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/16 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"6d91eda5a120a4a18273d82fed6777b3efcce8cc","subject":"Fix some trivial sign-compare compiler warnings"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-01-16 11:22:09.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"29599f765fa30af61ddcbe1bc053fbe13a2b3178":{"kind":"REWORK","_number":17,"created":"2025-02-03 18:19:12.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/17","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/17","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/17","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/17 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-03 18:19:00.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"4d7aa213f984614d97673c13a7a2ee57688d925b":{"kind":"REWORK","_number":18,"created":"2025-02-04 08:45:03.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/18","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/18","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/18","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/18 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-04 08:44:43.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"7fb4012edb35ce8868d0ef8af270dca3d374532a":{"kind":"REWORK","_number":19,"created":"2025-02-07 13:00:06.000000000","uploader":{"_account_id":1000003,"name":"plaisthos","display_name":"Arne Schwabe","email":"arne-openvpn@rfc2549.org","username":"plaisthos"},"ref":"refs/changes/06/806/19","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/19","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/19","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/19 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"060ead650450553214dad3e9856c500deb672bba","subject":"Adding AWS-LC to the OpenVPN CI"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2024-10-17 17:50:02.000000000","tz":120},"committer":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-07 12:59:41.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\n"},"branch":"refs/heads/master"},"9f4670fc718a8c16280d60c3e2d4ad29cffa04c4":{"kind":"TRIVIAL_REBASE_WITH_MESSAGE_UPDATE","_number":20,"created":"2025-02-12 18:02:57.000000000","uploader":{"_account_id":1000002,"name":"cron2","display_name":"Gert Doering","email":"gert@greenie.muc.de","username":"cron2"},"ref":"refs/changes/06/806/20","fetch":{"anonymous http":{"url":"http://gerrit.openvpn.net/openvpn","ref":"refs/changes/06/806/20","commands":{"Branch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git checkout -b change-806 FETCH_HEAD","Checkout":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull http://gerrit.openvpn.net/openvpn refs/changes/06/806/20","Reset To":"git fetch http://gerrit.openvpn.net/openvpn refs/changes/06/806/20 \u0026\u0026 git reset --hard FETCH_HEAD"}}},"commit":{"parents":[{"commit":"3ddfe26e491f9d74da54feb981116f7b8ef19a70","subject":"Fix oversight of link socket code change in Android code path"}],"author":{"name":"Arne Schwabe","email":"arne@rfc2549.org","date":"2025-02-12 16:13:11.000000000","tz":60},"committer":{"name":"Gert Doering","email":"gert@greenie.muc.de","date":"2025-02-12 16:26:46.000000000","tz":60},"subject":"Implement epoch key data format","message":"Implement epoch key data format\n\nWith DCO and possible future hardware assisted OpenVPN acceleration we\nare approaching the point where 32 bit IVs are not cutting it any more,\nespecially if we are limiting the IVs to the safe limits of AES-GCM where\nthe limit is more 2^29.\n\nTo illustrate the problem, some back of the envelope math here:\n\nIf we want to keep the current 3600s renegotiation interval and have\na safety margin of 25% (when we trigger renegotiation) we have about\n3.2 million packets (2*32 * 0.7) to work with. That translates to\nabout 835k packets per second. Currently, implementation trigger the\nrenegotiation at 0xff00000000 or at 7/8 of the AEAD usage limit.\n\nWith 1300 Byte packets that translates into 8-9 Gbit/s. That is far\nfrom unrealistic any more. Current DCO implementations are already in\nspitting distance to that or might even reach (for a single client\nconnection) that if you have extremely fast\nsingle core performance CPU.\n\nWith the AEAD usage limit, these limits are almost a factor of 8 lower\nso with the limit becomes 1-2 GBit/s. This is already reached without\nDCO on some platforms.\n\nThis introduces the epoch data format for AEAD data channel\nciphers in TLS mode ciphers. No effort has been made to support\nlarger packet counters in any other scenario since those are all legacy.\nThis uses the same approach of epoch keys as (D)TLS 1.3 does and switches\nthe data channel regularly for affected AEAD ciphers when reaching the\nusage limit.\n\nFor Chacha20-Poly1305, which does not suffer the same problems as AES-GCM,\nthe full 48 bit of packet counter are used only after that the same logic\nto switch to a new key as with AES-GCM is done.\n\nChange-Id: I00751c42cb04e30205ba8e6584530831e0d143c5\nSigned-off-by: Arne Schwabe \u003carne@rfc2549.org\u003e\nAcked-by: MaxF \u003cmax@max-fillinger.net\u003e\nMessage-Id: \u003c20250212161311.16888-1-gert@greenie.muc.de\u003e\nURL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg30845.html\nSigned-off-by: Gert Doering \u003cgert@greenie.muc.de\u003e\n"},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}