search

cryptimeleon / cryptimeleon.github.io

Documentation for the Cryptimeleon cryptography libraries.
Apache License 2.0
3 stars 0 forks source link

Developers Wiki: Coding guidlines #13

Closed rheitjoh closed 3 years ago

rheitjoh commented 3 years ago

(This issue has been imported from the Gitlab repository because it seems to not have been addressed yet)

Original Text (Issue 118)

Add coding guidelines to Wiki that includes stuff like

  1. what are the contracts that we follow (e.g. in serialization)
  2. What kind of security checks should we follow (e.g. group membership)
  3. our rules for constant time arithmetic (if we have some)
  4. ...

Comment by Jan Bobolz

On group membership: we should check whenever creating a (group) Element from user-supplied data. So any instantiated object should correspond to a valid Element (throw an exception otherwise).

Comment by Fabian Eidens

Can we enforce such things using findbugs rules?

Comment by Jan Bobolz

Can we enforce such things using findbugs rules?

Probably not (at least the first three points seems too complicated and diverse to check with a general rule). But it's generally a cool idea to think about adding some findbugs checks :)

Comment by Peter Günther

[at]feidens what are findbugs rules? I think we could implement a generic subgroup membership test given that the factorization of the group order is known. IEEE also proposes such checks that are basically:

  1. Check that proper representation of group element (e.g. that it fulfills the Weierstrass equiation of an element) [specific to group]
  2. Check that exponentiation with group order results in neutral element [generic]
  3. For generators: Check that exponentiation with any factor of group order does not result in neutral element [generic]

Check 2 might be expensive for large groups. For small cofactors a check based on exponentiation with cofactors might be more efficient. How to do this without introducing vulnerabilities to small subgroup attack will be part of the wiki.

Comment by Fabian Eidens

I think the findbugs rules were shown in our last meeting through the sonarqube example (e.g. code smell) or are there further questions?

rheitjoh commented 3 years ago

Seems like this issue went a bit offtopic (i.e. the whole findbugs discussion). This is also not an issue that can be "fixed", just some guidelines to keep in mind.