kpdyer / libfte Goto Github PK

Placeholder for testing that libfte works under Python3.

• In main README.md RegexEncoder should be DfaEncoder.

The build process is currently failing on Windows because the paths to re2 and gmp are wrong.

In setup.py we don't list "pycrypto" under install_requires.

We are currently not calling the fte.encrypt function when we call encode, this is due to poor encapsulation with the previous fte.record_layer calls.

Currently on Linux the fte/VERSION file is installed to /usr/local. However, it should be the in the python dist-packages directory.

The following script highlights a memory leak in libfte:

import fte.encoder

regex = '^(a|b)+$'
fixed_slice = 512
input_plaintext = 'test'

fteObj = fte.encoder.RegexEncoder(regex, fixed_slice)
for trials in range(10000):
  fteObj.encode(input_plaintext)

Using valgrind, we get:

$ valgrind --tool=memcheck --suppressions=valgrind-python.supp --leak-check=full --show-reachable=yes python -E -tt test.py
...
==11293== LEAK SUMMARY:
==11293==    definitely lost: 412 bytes in 2 blocks
==11293==    indirectly lost: 1,043 bytes in 24 blocks
==11293==      possibly lost: 27,220 bytes in 77 blocks
==11293==    still reachable: 3,259,770 bytes in 567 blocks
==11293==         suppressed: 0 bytes in 0 blocks

Increasing/decreasing the valid trials in the test script results in an increase/decrease in the still reachable bytes, as reported by valgrind.

This specific bug manifests itself on fteproxy Tor bridges when run for many many months. It appears that only a few bytes are leaked by each fte.encode call.

This example is out of date: https://github.com/kpdyer/libfte/blob/master/examples/example1.py

The RegexEncoder module no longer exists.

The AES block cipher mode that is currently being used is ECB. This strikes me as an unusual design decision that I have not seen justification for in the publication, documentation, or code.

ECB mode is perhaps the most difficult block cipher mode to use while still maintaining the security properties that AES seeks to provide.

My intention in filing this issue is to prompt changing to a new block cipher mode or allow the rationale to be more clearly documented.

This may be an issue in regex2dfa but I came across it while exploring the docs/ in this project...
This produces behaviors I find unexpected and I believe it has something to do with mixing items in a regex grouping of odd and even lengths.

import regex2dfa
import fte.encoder

regex = '^(ab|d)+$'
fixed_slice = 512
input_plaintext = 'THIS IS A TEST'

dfa = regex2dfa.regex2dfa(regex)
fteObj = fte.encoder.DfaEncoder(dfa, fixed_slice)

ciphertext = fteObj.encode(input_plaintext)

print 'ciphertext (%s) = %s' % (str(len(ciphertext)), ciphertext)

Placeholder for the debian related tasks to make libfte debian-ready.

Make sure that we have our dependencies (libgmp and pycrypto) listed in README, setup.py, and debian/control.

https://trac.torproject.org/projects/tor/ticket/13187

Raised by Yawning: https://trac.torproject.org/projects/tor/ticket/11637