denozord/strongswan-ext
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

proposal: Don't specify key length for ChaCha20/Poly1305

Browse Source 
This algorithm uses a fixed-length key and we MUST NOT send a key length
attribute when proposing such algorithms.

While we could accept transforms with key length this would only work as
responder, as original initiator it wouldn't because we won't know if a
peer requires the key length.  And as exchange initiator (e.g. for
rekeyings), while being original responder, we'd have to go to great
lengths to store the condition and modify the sent proposal to patch in
the key length.  This doesn't seem worth it for only a partial fix.
This means, however, that ChaCha20/Poly1305 can't be used with previous
releases (5.3.3 an newer) that don't contain this fix.

Fixes #2614.

Fixes: 3232c0e64e ("Merge branch 'chapoly'")
This commit is contained in:
Tobias Brunner
2018-04-12 16:07:13 +02:00
parent b2163409cc
commit 5a7b0be294
4 changed files with 20 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/libstrongswan/tests/suites/test_proposal.c
+17
View File
@@ -281,6 +281,19 @@ START_TEST(test_unknown_transform_types_select_success)
}
END_TEST
START_TEST(test_chacha20_poly1305_key_length)
{
proposal_t *proposal;
uint16_t alg, ks;
proposal = proposal_create_from_string(PROTO_IKE, "chacha20poly1305-prfsha256-ecp256");
proposal->get_algorithm(proposal, ENCRYPTION_ALGORITHM, &alg, &ks);
ck_assert_int_eq(alg, ENCR_CHACHA20_POLY1305);
ck_assert_int_eq(ks, 0);
assert_proposal_eq(proposal, "IKE:CHACHA20_POLY1305/PRF_HMAC_SHA2_256/ECP_256");
proposal->destroy(proposal);
}
END_TEST
Suite *proposal_suite_create()
@@ -313,5 +326,9 @@ Suite *proposal_suite_create()
tcase_add_test(tc, test_unknown_transform_types_select_success);
suite_add_tcase(s, tc);
tc = tcase_create("chacha20/poly1305");
tcase_add_test(tc, test_chacha20_poly1305_key_length);
suite_add_tcase(s, tc);
return s;
}