I am trying to use cpabe functionality of the Charm Crypto library. Specifically I am using the abenc_bsw07 scheme.
Is there a way to define more complex policies and attributes than the ones in the examples:
attributes = ['ONE', 'TWO', 'THREE']
access_policy = '((four or three) and (three or one))'
I would like to be able to do stuff similar to the cpabe (http://acsc.cs.utexas.edu/cpabe/tutorial.html) implementation. There attributes have values and policy can contain equality or larger/smaller relations.
I can also use an alternative scheme if it supports the desired functionality.
There are several options for policy expressiveness. Some ABE schemes only support pure AND-policies or pure OR-policies. Some only support policies in a specific form such as CNF or DNF.
Bethencourt's CP-ABE supports policy trees with threshold nodes. Nestable threshold nodes is enough to achieve numerical attributes and if you want an example of that you can look into libbswabe.
Let's assume we have four attributes A, B, C and D=5. A threshold policy could look like this: 2 of (A, B, C) which means that it is only necessary have 2 or more attributes from the list to fulfill the policy and be able to decrypt the ciphertext. An AND-gate (A AND B) is nothing more than 2 of (A, B) and an OR-gate (A OR B) is nothing more than 1 of (A, B).
Numerical policies such as A AND D<=24 will lead to rather large policy trees when parsed, because the numerical attributes are encoded in binary and then many masks for each bit position are generated. This is a very expensive operation (encryption and decryption that is).
Charm doesn't support threshold policies. The policy parser (charm.toolbox.policytree) slightly supports numerical attributes, but there is no code to handle numerical attributes in attribute sets. The algorithm to create the bitmask attributes is also missing.
It should be fairly easy to add threshold gates, but it would be necessary to change the binary tree to a tree with arbitrary number of child nodes (see charm.toolbox.node).
The changes wouldn't be complicated, but it would be a bit too much. If you are interested to do these changes you should. If you manage to add these features without breaking existing code (run charm tests), you can be fairly certain these changes will be merged into master.