As the SD-Card only has 32MB of RAM, from which only around the half of it is free during run time, in the current implementation one can only encrypt images which have a size lower than ~15-20MB.
It would be nice if the cryptosd wouldn't try to read in the whole file, but read in multiple smaller chunks an process them. However as we saw during our benchmark, the longest part of the encryption is the IO, and particularly the writing out of the file. So this would cause more IO-overhead, which one might find undesired.
As the SD-Card only has 32MB of RAM, from which only around the half of it is free during run time, in the current implementation one can only encrypt images which have a size lower than ~15-20MB.
It would be nice if the cryptosd wouldn't try to read in the whole file, but read in multiple smaller chunks an process them. However as we saw during our benchmark, the longest part of the encryption is the IO, and particularly the writing out of the file. So this would cause more IO-overhead, which one might find undesired.