benhj / knoxcrypt Goto Github PK

Currently it is only possible to create / open a container in default root block mode

Currently, whenever the underlying image needs to be accessed, it creates a local image stream. Consequently, it needs to seek to the correct position each time. When reading from and writing to files, this amounts to one hulluva amount of seeking

Currently there is much duplication in the test code when creating a CoreBFSIO struct in multiple places. A factory function that returns an instance will reduce this.

An example output of df -h yields:

teasafe@osxfuse0 0Bi 0Bi 0Bi 100% 0 0 100% /testMount

Always.

Presently, a relatively weak sha256 key derivation function is used. Suggest switching to scrypt.

Currently, to access an image and inspect its contents, addition and removal of content etc. all require using FUSE. However, it is also feasibly possible to treat the teasafe image like any container format (zip, rar etc.). A simple CLI application could be easily implemented to do just that. It might feature a simple menu to

(i) list contents
(ii) copy file
(iii) remove file
(iv) create folder

etc...

With the introduction of the EntryInfoCache, a critical question remains: how should entries be invalidated / updated?

In a similar way to having a CLI to inspect the image's content, attempt to implement a GUI (similar to what any Zip management application (e.g. WinZip) typically does).

Consider using a mersenne twister PRNG for generating the IV; should be a relatively straight forward addition. Support in both C++11 and boost

E.g. this allocator code:

int64_t bmp_alloc(uint64_t *bmp, int64_t slots){
  // search for the first 0 bit, set it to 1,
  // then return the slot
  // return -1 if nothing found
  slots /= 64; // checking 64 slots at a time
  for (int64_t loop = 0; loop < slots; loop++){
    if (*bmp == 0xFFFFFFFFFFFFFFFFLL){
      // this area is full, go to the next area
      bmp++;
      continue;
    }
    // we're guaranteed at least one bit is 0
    int pos = ffsll(~*bmp) - 1;
    *bmp |= 1LL << pos; // set the bit at pos
    return loop * 64 + pos;
  }
  return -1;
}

From http://syntheti.cc/article/kongs-garbage-collector/

Could be similarly used to do far quicker bitmap lookup. Presently, I'm checking bit by bit

When a file is added to the root, the file is added but a following assert on fileExists fails. Made root folder shared to ensure that the same copy of the root folder is being used throughout

There are some issues with the source code that mainly involve cstring or string.h not being included for the definition of functions like memcpy() and strlen(). I was able to resolve the compilation issues by including the needed header. Also the flags in the makefile needed a slight adjustment for fuse. I have made a patch that resolves the problem. How may I send it to you?

Since introducing cryptopp. Seems to be fine on mac

Currently, adding a sub-volume to a teasafe image is only possible at the time of image creation. It is feasibly possible however to take a pre-existing image and add a new sub-volume to it.

Notably BFSTest and FolderEntryTest

Since the root of the filesystem is determined by the root folder, we can potentially mount any folder inside of the bfs image as the root folder. This opens up the possibility of having multiple partitions within the same image and allowing the user to choose the partition when mounting the fs image.

Encryption is currently hardcoded in to one class. Be better to have an interface that we extend from so that we can try different algorithms.

Unless I switch from using crypto++ to something different, this will have to wait until crypto++ supports it.

Currently this is only supported in the cli utils (fuse layer and shell)

It's great that you are interested in cryptography, but please do some reading before you actually implement a program which does encryption.

"is this key-gen secure? probably not...use at own risk"
Nope, state of the art software uses special key derivation algorithms to prevent brute force attacks via specialized hardware.
So use something like scrypt or bcrypt to prevent a potentially powerful attacker from simply brute forcing the key.

I didn't look too closely, but it seems that your XTEA implementation is potentially vulnerable to a timing side channel attack.
Please use a library like nacl to avoid implementation based attacks.

Could you please provide some more documentation on how the data is stored on disc? There have been attacks where a vulnerable cipher mode was used to inject a backdoor.
It looks like you are using CTR, which isn't vulnerable to this attack, however the layout of your file system is nevertheless critical in regards to meta data leakage.

MT isn't cryptographically secure, apparently

In the current implementation, the IV is a random number stored at the beginning of the teasafe container. This is prone to a watermarking attack. A better approach would salt it with a hash of the key making it unpredictable. See http://en.wikipedia.org/wiki/Disk_encryption_theory#Encrypted_salt-sector_initialization_vector_.28ESSIV.29

Strange behaviour; steps to reproduce --

(i) recursively copy content to a newly created image
(ii) recursively delete it,
(iii) create a new sub folder
(iv) cd into the new sub folder.
(v) attempt to recursively copy content in to the newly created sub folder

Step (v) results in a freeze; subsequently killing the teasafe process and re-mounting the image then appears to be impossible. Suggests that there is a problem with how entries are deleted and subsequently cleared after deleting (inc. metadata) all of which appears to secondarily corrupt the image

This is probably a bug. Needs investigating. Arose after fixing previous bug.

Entries can be moved from one folder to another but not inside of the same folder. Not sure why. An entry metadata retrieval runtime error is thrown when attempting to do so

If a root folder is created before anything else, it self-references itself in a very weird recursive manner.

If something else is created first, then every other folder seems to be fine

The image should be able to grow as more files are added