jhuisi / charm Goto Github PK

This should be an MNT224 curve, we passed it an SS512
This should have failed cleanly, instead it fails with:

File "schemes/abenc/abenc_lsw08.py", line 33, in abenc_lsw08.KPabe
Failed example:
ciphertext = kpabe.encrypt(private_key, msg, attributes)
Exception raised:
Traceback (most recent call last):
File "/usr/lib/python3.2/doctest.py", line 1288, in __run
compileflags, 1), test.globs)
File "<doctest abenc_lsw08.KPabe[7]>", line 1, in
ciphertext = kpabe.encrypt(private_key, msg, attributes)
File "schemes/abenc/abenc_lsw08.py", line 111, in encrypt
return {'E1':(pk['e(gg)_alpha'] ** s) * M, 'E2':pk['g_G2'] ** s, 'E3':E3, 'attributes':attr_list }
KeyError: 'e(gg)_alpha'

"""
>>> from schemes.example_values import pairing_SS512_val as msg
>>> groupObj = PairingGroup('MNT224')
>>> kpabe = KPabe(groupObj)
>>> (public_key, master_key) = kpabe.setup()
>>> policy = '(ONE or THREE) and (THREE or TWO)'
>>> attributes = [ 'ONE', 'TWO', 'THREE', 'FOUR' ]
>>> private_key = kpabe.keygen(public_key, master_key, policy)

For conveniece, we are using a pre-defined message
>>> ciphertext = kpabe.encrypt(private_key, msg, attributes)

>>> kpabe.decrypt(ciphertext, mykey)
[8498626471746535541889196006969623245883442038940767658411896849230802260262151353691177896167637279292812138807029583456775233580306113979341887791855557, 6966939460945789223279096602928312619651295009575045207502056308294974480025386597816838423778648241850303711370830167285562786901756561121522858944449876] 
"""

Pyparsing crashes when the policy string contains attributes that have delimiting characters.
For example, the policy string (JHU_Professor AND JHMI_Staff) will cause pyparsing to crash.

Allowing delimiting characters in the policy string will be important in the muti authority setting of Attribute Based Encryption since each attribute must be unique. ie. it is important to distinguish what JHU calls "staff" and what JHMI calls "staff".

>>> from charm.core.math.integer import integer
>>> x = integer(3,101)
>>> x ** (-1)
34 mod 101
>>> 1/x
zsh: segmentation fault (core dumped)  python3

Expected result: same as x ** (-1)

Right now, there is a hole in our documentation in terms of how to initialize schemes with group parameters (especially for pairings). So, we need to be explicit on all the different ways users can generate group parameters from type a (SS curves) to type d (MNT curves).

This is a base class wrapper for Symmetric encryption schemes. It's analogous to PKEnc. I would also like to create a subclass that implements a bunch of ciphers/modes of operation (basically you configure it with AES-GCM mode and then use it like a PKEnc).

/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:25:10:
fatal error: 'stdio.h' file not found

Apparentlly a known issue the latest version of XCode with python. Not related to our project, but it may be something we need to have a work around for

Right now Charm only encrypts strings or bytes objects -- buffers in memory. However, for things like symmetric encryption of large files we will need the ability to process streams of data. We should think about how to handle these.

We need to add generic functions to harden against timing attacks.

Off hand, the main one we need is a byte/string compare that at minimum leaks no information and at a maximum is constant time.

Lines 521-526... I added armv4b so cross compiling would not fail during the compiler test as -m64 is not supported, and by default configure checks the arch of the compilation machine. Not an eloquent solution.

if cross compiling, cannot launch a program, so make a static guess

case "$cpu" in
armv4b|hppa|m68k|mips|mips64|ppc|ppc64|s390|s390x|sparc|sparc64)
bigendian=yes
;;
esac

Adapters by definition modify existing schemes and should be treated and tested in a different way. Therefore, remove all the adapters from schemes directory into their own dir.

Really the system should try to build and install for pythong 2* and 3 if possible and fall back to whichover one is present and warn on the other

The integer routines in charm.core.math.integer give wrong results when combined with Python integers. I would expect y and z to have the same value as w, but z loses the modulus, whereas y actually swaps the operands to mod:

ubuntu% python3
Python 3.2.3 (default, Oct 19 2012, 20:13:42) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import charm.core.math.integer as chint
>>> x = chint.integer(12345678)
>>> x
12345678
>>> y = 100 % x
>>> y
78 mod 100
>>> z = chint.integer(100,x)
>>> z
100
>>> w = chint.integer(100,int(x))
>>> w
100 mod 12345678

There are a few other bugs I have run into; might it make more sense to use the gmpy/gmpy2 libraries (http://code.google.com/p/gmpy/) instead in Charm?

(Note: I haven't used them myself but they seem a bit cleaner than Charm's version, if only by virtue of having documentation.)

The correct python3 path on ubuntu is
/usr/local/lib/python3.1/dist-packages

However, none of the standard system calls return this directory directly.

distutils.sysconfig.get_python_lib(0, 0, '/usr/local')
'/usr/local/lib/python3/dist-packages'
distutils.sysconfig.get_python_lib(0, 1, '/usr/local')
'/usr/local/lib/python3.1'
distutils.sysconfig.get_python_lib(1, 0, '/usr/local')
'/usr/local/lib/python3/dist-packages'
distutils.sysconfig.get_python_lib(1, 1, '/usr/local')
'/usr/local/lib/python3.1'

Currently we use a broken padding scheme of merely appending information. We need something like pkcs 1.5 padding or the like.

When doing a source build setup.py provides an easy-install.pth (path file) that points to charm crypto and distribute. This is fine, but on an actual dev box... this might already be in use and we aren't in the business of overwriting/appending that file. My solution in the windows installer is to add a charm.pth file with the line: ./charm-crypto-{version}-py{version}-win32.egg.

Pickle was never designed to be secure and is susceptible to arbitrary code execution if unpickling untrusted data. Need to switch to a safer serialization tool such as JSON.

These schemes have separate ec and integer variants. Since we have a common group interface, this should be removed

This is a problem for jenkins since by default the directory it puts the text in has spaces in it

Right now authenticated encryption is done via a mac that is keyed with sha1(enc_key||"salt"). This is safe in the random oracle model, it is not in the standard model.

We should use a better extractor

Modify all crypto functions and test examples to operate purely on bytes and leave string conversion up to either the dev or another tool we provide.

Repos constantly. No clue whats wrong
On mike's system desktop :

minnie:charm ian$ make test
/opt/local/bin/python3.2 -m unittest discover -p "*_test.py" schemes/test/

.........................................................

Ran 57 tests in 16.241s

OK
find . -name '_.pyc' -delete
/opt/local/bin/python3.2 -m unittest discover -p "__test.py" charm-framework/test/toolbox/
make: *** [test-charm] Bus error: 10

Need to collapse param files for pbc pairing module into a python file with easy to remember identifiers e.g., MNT### or SS###, etc

There should be a way to run tests against the installed code as well. This should not be the default , but it is necessary to test certain things

from charm.toolbox.integergroup import integer
integer(integer(3))

the link is broken

iv  = '6543210987654321' # static IV (for testing)    
PRP_method = selectPRP(self.alg, (key, mode, iv))

Should not be used. IV should be random

what it says above

1. try to remove custom version dependency
2. get rid of --sphinx=which sphinx as arg to ./configure.sh

In order to support tox testing, config.mk is included in SDIST. This is not the best idea ever.

The resolution probably will fix issue #38 as well : handling dependencies.

For source installs, we shouldn't do it. Just install pyparsing and gmp yourself such that ld can find them and then run the standard python installation process

>>> from charm.core.math.integer import integer
>>> x = integer(101)
>>> integer(33,x)
33
>>> integer(33,int(x))
33 mod 101

Expected behavior: both versions should give me 33 mod 101.

Pyparsing 1.3 ships in ubuntu and we need 1.5.5. Because of the way ./configure works, we don't install our version. Moreover, we probably can't do the nieve install anyway since that would overwrite the system version

Although extract handles strings for IDs , encrypt does not

Currently, the pairing module defaults to a deterministic PRNG since there is no /dev/urandom on Windows. Need to pull from the appropriate source of entropy for Win systems.

Multiple calls to PairingGroup() within the same unit test suite results in a segmentation fault.

The following test class (tests/interface_ABEnc_test.py) succeeds if only one of the test* methods is invoked.
When two or more methods that contain a PairingGroup() statement, the test finishes with a segmentation fault.

class Test(unittest.TestCase):    
    def testIBE_bb03(self):
        group = PairingGroup('d224.param', 1024)
        M = group.random(GT)
        self.myCorrectnessTest(IBE_BB04, group, M)

    def testIBE_Franklin(self):
        group = PairingGroup('d224.param', 1024)
        M = "hello world!!"
        self.myCorrectnessTest(IBE_BonehFranklin, group, M)
 .
 .

if __name__ == "__main__":
    unittest.main()

fails with benchmark import error

has also failed with pyparsing error.

group = PairingGroup('a.param')
help(group)

No methods for retrieving the order of the group are found.
This is a feature feature request.
The group order is within the parameter file on the "r" line

Although identities need to be group elements in the boneh boyen scheme, it does not fail when passed a string. Instead it appears to implicitly convert ID to some group element in a way that is not deterministic (i.e. one cannot just encrypt to the identity string)

This is shown by the ibe_adapt_hybrid scheme

Currently the symmetric key encryption abstraction takes a byte array as a key. Realistically, the question of how to extract
a symmetric key from a group element is not a question that should be defined by either the symmetric scheme or the hybrid scheme, it should be a property of what model we are working in.

Currently the integer module takes unicode strings. This is problematic because when some crypto system is realized using the integer library, we typically encrypt using a hybrid model that encodes the symmetric key in the integer model. Unfortunately, the unicode strings accepted currently don't actually represent the full entropy one would want for key material.

Ideally this should be fixed to use bytes in python 3 and fall back to python 2 style strings if necessary. In both cases, this would mean the ability to pass the full range of bits to the encoding function.

I find it a bit confusing the way the integer handles initial negative values.

To me it seems like integer(-3, 10000) would either error, or return the modular inverse of 3.
I would also expect integer(3) * -1 have similar behavior.

Instead we see behavior like
integer(3, 10000) * -1 #=> 55340232221128654845 mod 10000
integer(3) * -1 #=> 55340232221128654845

Upon inspection it makes perfect sense that this does not compute the intended result, but it can lead to hard to track down bugs.

I propose that if a negative number is applied to an integer (or a modular integer) an error or warning is displayed to the user.

Thanks for all the hard work,

Sky

With traditional python objects, exponentiations on unsupported objects throws an error eg:

>>> b=b'test'
>>> b ** 3
Traceback (most recent call last):
 File "<input>", line 1, in <module>
 TypeError: unsupported operand type(s) for ** or pow(): 'bytes' and 'int'

However, when this is done with an element object, a segmentation fault is thrown.
Type checking is needed in order to avoid segmentation faults

>>> from charm.integer import *
>>> rand = init()
>>> p = rand.randomPrime(1024)
>>> b'test' ** p
Segmentation fault

it seems hybrid encryption should be a utility provided by the framework and not something we are writing everytime. Hoepfully it would be something you could compose by providing asymmetric scheme and a symmetric scheme.

Here's another problem I ran into:

>>> from charm.toolbox.integergroup import IntegerGroupQ
>>> g = IntegerGroupQ()
>>> g.paramgen(32)
>>> g.p
3673281863
>>> g.q
1836640931
>>> gen = g.randomGen()
>>> gen
114476042 mod 3673281863
>>> x = g.random()
>>> x
599153896 mod 1836640931
>>> y = g.random()
>>> y
996126290 mod 1836640931
>>> z = x - y
>>> z
-396972394 mod 1836640931
>>> gen ** z
zsh: floating point exception (core dumped)  python3

The problem is that z is not reduced to be in the range of [0, 1836640931), which results in a negative exponent being passed to GMP, which leads to an exception. I can fix this by adding a call to z.reduce() — am I supposed to be making these calls after every arithmetic calculation?

from charm.core.math.integer import integer
s = integer(35)
s.reduce()

The output is the c error 'Floating point exception: 8' and python crashes.

Title says it all. :-)

More of a reminder for myself... we need to exclusively support llvm for OS X 10.7+ as python installers from python.org will have the documented error:

/Developer/SDKs/MacOSX10.6.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory
lipo: can't figure out the architecture type of: /var/folders/1d/6brkk4q10jq9fk81wvjgdjdw0000gn/T//ccE80Gx7.out
error: command 'gcc-4.2' failed with exit status 1
make: *** [build] Error 1

The problem is that stdarg.h in this particular directory is for llvm not gcc-4.2. The fix for this is:
CC=/usr/bin/gcc /Library/Frameworks/Python.framework/Versions/3.2/bin/python3.2 setup.py build

At the moment make tries to install gmp and pbc. Currently, it assumes they are not installed the first time it runs, then assumes that they are installed at any later point. The standard solution to this is to tell the user what is missing during ./configure.

Hello,

I am looking for Python implementations of "ring signature".
From:https://github.com/JHUISI/charm/wiki/Cryptographic-schemes-and-protocols
I did not found basic:

For instance:
"How to leak a secret" from Rivest et Al 2001
"Short Linkable Ring Signatures for E-voting, E-cash and Attestation" Patrick P. Tsang and Victor K. Wei 2004

It would be great to have them in Charm

Thanks

Laurent