Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PQC: Classic McEliece #3883

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

FAlbertDev
Copy link
Collaborator

@FAlbertDev FAlbertDev commented Jan 11, 2024

Pull Request Dependencies

Description

This PR relates to the Classic McEliece KEM as specified in this ISO draft. It also contains the instances defined in the NIST Round 4 submission. The test cases were generated using the NIST submissions reference implementation. Note that Classic McEliece (module cmce) is not the original McEliece Algorithm that is implemented in Botan's mce module. See the Classic McEliece homepage, for a brief comparison.

TODO Tracker

@coveralls
Copy link

coveralls commented Jan 11, 2024

Coverage Status

coverage: 91.304% (+0.2%) from 91.14%
when pulling 083e153 on Rohde-Schwarz:pqc/classic_mceliece
into e24dd8a on randombit:master.

@reneme reneme added this to the Botan 3.4.0 milestone Jan 11, 2024
@FAlbertDev FAlbertDev force-pushed the pqc/classic_mceliece branch 4 times, most recently from f73829f to e505390 Compare January 19, 2024 14:53
@atreiber94 atreiber94 force-pushed the pqc/classic_mceliece branch 2 times, most recently from 04b9314 to 190261d Compare January 19, 2024 15:59
@reneme reneme self-requested a review January 22, 2024 09:33
@FAlbertDev

This comment was marked as resolved.

@reneme reneme force-pushed the pqc/classic_mceliece branch 6 times, most recently from 7662592 to 2a3e60f Compare January 23, 2024 15:55
@reneme

This comment was marked as resolved.

Copy link
Collaborator

@reneme reneme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This mostly looks at cmce_decaps.cpp, cmce_encaps.cpp and cmce.cpp, noting many minor code style things and a few suggestions for alternative code structuring. Not looking into the Classic McEliece specifics at all here.

src/build-data/oids.txt Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_types.h Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_encaps.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_encaps.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_encaps.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_encaps.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_encaps.cpp Outdated Show resolved Hide resolved
src/lib/utils/strong_type.h Outdated Show resolved Hide resolved
Copy link
Collaborator

@reneme reneme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First pass on cmce_field_orderings.cpp. I'm somewhat concerned that this isn't very efficient. But it may well be "good enough". Should we profile that?

src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_field_ordering.cpp Outdated Show resolved Hide resolved
Copy link
Collaborator

@reneme reneme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More comments. I didn't look at cmce_parameter_set.*, cmce_parameters_* and cmce_poly.*, yet.

src/lib/pubkey/classic_mceliece/cmce_keys_internal.cpp Outdated Show resolved Hide resolved
src/lib/utils/strong_type.h Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce.cpp Outdated Show resolved Hide resolved
Comment on lines 41 to 49
// TODO: Only for test instances. Remove on final PR
size_t m = Classic_McEliece_GF::log_q_from_mod(mod);

for(int i = static_cast<int>(m) - 2; i >= 0; --i) {
x ^= CT::Mask<uint32_t>::expand((uint32_t(1) << (i + m)) & x)
.if_set_return(static_cast<uint32_t>(mod.get()) << i);
}

return GF_Elem(static_cast<uint16_t>(x));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to remove (and probably replace by some exception?)

src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_matrix.cpp Outdated Show resolved Hide resolved
Comment on lines 247 to 295
Code_Word Classic_McEliece_Matrix::mul(const Classic_McEliece_Parameters& params, const Error_Vector& e) const {
auto s = e.subvector(0, params.pk_no_rows());
auto e_T = e.subvector(params.pk_no_rows());
auto pk_slicer = BufferSlicer(m_mat_bytes);

for(size_t i = 0; i < params.pk_no_rows(); ++i) {
auto pk_current_bytes = pk_slicer.take(params.pk_row_size_bytes());
auto row = secure_bitvector(pk_current_bytes, params.n() - params.pk_no_rows());
row &= e_T;
s.at(i) = s.at(i) ^ row.has_odd_hamming_weight();
}

BOTAN_ASSERT_NOMSG(pk_slicer.empty());
return s.as<Code_Word>();
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This produces quite a few copies and allocations. If that's in the implementation's hot path, we should probably want to have another look. Here's which (I believe cause allocations/copies):

  1. .subvector() always creates a new bitvector and copies the content into a newly allocated buffer,
  2. the c'tor of bitvector copies the passed-in buffer (particularly pk_current_bytes
  3. .as<> produces a copy of the bitvector with a new type

For (3): This could already be the right type using e.subvector<Code_Word>(), no?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some context: This function is called once per encapsulation. Also, e and s are pretty small, while m_mat_bytes is gigantic. Therefore, 1) and 3) are not critical; I'll apply your suggestion for 3) anyway. I don't know how we can prevent 2) without having something like a bitvector view or dropping the bitvector altogether.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'll have a timeboxed look into a bitvector that doesn't own its underlying storage. Perhaps that isn't too hard to achieve, especially when we can limit it to byte-aligned subvectors.

Copy link
Collaborator

@reneme reneme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done with a first pass on the implementation. Don't get put off by the number of comments. Most are just C++ style nits and smaller programming suggestions.

That's really good work! 😃

Comment on lines 48 to 57
/// Reduced instances for side channel analysis (Self-created test instance with
/// m=8, n=128, t=8, f(z)=z^8+z^7+z^2+z+1, F(y)=y^8+y^4+y^3+y^2+1)
/// Minimal instance without semi-systematic matrix creation and no plaintext confirmation
test,
/// Minimal instance with semi-systematic matrix creation and no plaintext confirmation
testf,
/// Minimal instance without semi-systematic matrix creation and with plaintext confirmation
testpc,
/// Minimal instance with semi-systematic matrix creation and with plaintext confirmation
testpcf
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: remove before merging

src/lib/pubkey/classic_mceliece/cmce_parameter_set.h Outdated Show resolved Hide resolved
Comment on lines 27 to 32
/**
* @returns ceil(n/d)
* TODO: Remove once LMS is merged
*/
constexpr size_t ceil_div(size_t n, size_t d) {
return (n + d - 1) / d;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-evaluate before merging this.

src/lib/pubkey/classic_mceliece/cmce_parameters.h Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_parameters.h Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_poly.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_poly.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/cmce_poly.cpp Outdated Show resolved Hide resolved
src/lib/pubkey/classic_mceliece/info.txt Outdated Show resolved Hide resolved
src/lib/utils/bit_ops.h Outdated Show resolved Hide resolved
@FAlbertDev
Copy link
Collaborator Author

Thanks a lot for your extensive review, @reneme! I addressed your suggestions and am optimistic that this PR is ready to drop its Draft status 🎉. Note that some suggestions that depend on other PRs are still open, which are not critical, though. Also, note that an extensive side-channel analysis is still in progress.

@FAlbertDev FAlbertDev marked this pull request as ready for review February 5, 2024 14:49
constexpr bitref& operator^=(bool other) noexcept { return assign(this->is_set() ^ other); }

private:
constexpr bitref& assign(bool bit) noexcept { return (bit) ? set() : unset(); }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed, DATA identified this line as a leakage during our SCA review.

Due to the ? operator, a control-flow difference is observed based on the boolean input bit variable.

The assign() routine is used within the push_back() routine, which in turn is used within the decode() routine. This may allow an adversary to observe the error vector e and, hence recover the shared secret.

We suggest to perform both the set() and unset() functions with the input as a mask, for example:

         private:
            constexpr bitref& assign(bool bit) noexcept {
                const block_type assign_mask = 0 - static_cast<block_type>(bit);
                this->m_block |=  (this->m_mask &  assign_mask);
                this->m_block &= ~(this->m_mask & ~assign_mask);
                return *this;
            }

In our case, this results in the following instructions - without any conditional branch based on the input:

[ ... ] 
                                         const block_type assign_mask = 0 - static_cast<block_type>(bit);
41d397: 41 f7 dc                   neg %r12d
[ ... ]
                                         this->m_block |= (this->m_mask & assign_mask);
41d3ab: 44 89 e1                   mov %r12d,%ecx
41d3ae: 21 c1                      and %eax,%ecx
                                         this->m_block &= ~(this->m_mask & ~assign_mask);
41d3b0: f7 d0                      not %eax
                                         this->m_block |= (this->m_mask & assign_mask);
41d3b2: 0a 0a                      or (%rdx),%cl
                                         this->m_block &= ~(this->m_mask & ~assign_mask);
41d3b4: 44 09 e0                   or %r12d,%eax
41d3b7: 21 c8                      and %ecx,%eax
[ ... ]

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your analysis and your report! I applied your fix using Botan's constant-time helper class (7a0fe59)

@@ -1,6 +1,8 @@
/*
* An abstraction for an arbitrarily large bitvector that can
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reneme the code still contains some artefacts for varying the underlying data type that we'd ideally want to get rid of.

Comment on lines 35 to 31
CT::Mask<uint64_t> bit_at_mask(uint64_t val, size_t pos) {
return CT::Mask<uint64_t>::expand((val >> pos) & 1);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using this method in the respective context implies a side channel in clang 17. If I change it to

CT::Mask<uint64_t> bit_at_mask(uint64_t val, size_t pos) {
   return CT::Mask<uint64_t>::expand((uint64_t(1) << pos) & val);
}

It is fine. It seems that clang somehow sees that the input to expand can only be 1 or 0. I could not find the exact source of the problem (since I'm bad with assembly), but I thought the value barrier should prevent such cases. Maybe some other parts in the calling context cause this to happen, though. I cannot (yet) reproduce this case in Godbolt either, so it seems to be a very special case...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: In this and similar cases, clang-17 seems to use a bt instruction, which valgrind does not process correctly (see here). In the alternative version, no such instruction is generated. Note that both versions DO NOT induce any side channels, according to our assembly analysis.

FAlbertDev and others added 13 commits October 18, 2024 08:42
- constant time conditional swap with mask
- floor_log2

Co-Authored-By: Amos Treiber <amos.treiber@rohde-schwarz.com>
This is an implementation of the Classic McEliece KEM according to the
NIST Round 4 submission and the ISO draft 20230419.

Co-Authored-By: Amos Treiber <amos.treiber@rohde-schwarz.com>
Co-Authored-By: Jack Lloyd <jack@randombit.net>
Co-Authored-By: Fabian Albert <fabian.albert@rohde-schwarz.com>
This allows extracting subvectors of the bitvector as unsigned
integral bit masks.
Use CT::poison/unpoison for CMCE. Simultaneously, fixes some
constant-time issues in the CMCE implementation that may leak some
information about the pivots (for the semi-systematic matrix form).

Co-Authored-By: René Meusel <rene.meusel@rohde-schwarz.com>
@reneme
Copy link
Collaborator

reneme commented Oct 18, 2024

Rebased and resolved several conflicts after all other PQC algorithms got merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants