The official SQLite Encryption Extension does not support encrypting in-memory databases per their documentation: https://www.sqlite.org/see/doc/trunk/www/readme.wiki
Limitations
TEMP tables are not encrypted.
In-memory (":memory:") databases are not encrypted.
Bytes 16 through 23 of the database file contain header
information which is not encrypted.
Does SQLCipher have these same limitations?
Related
Realm supports encrypting the database file on disk with AES-256+SHA2 by supplying a 64-byte encryption key when creating a Realm.
Since the Realm Mobile Platform is self hosted (inhouse or via cloud) - does that effectively also mean that this same database file encryption is available ? I'm assuming 'yes' but since I was always taught "never assume" I wanted to ask the question here.
Yes, the same encryption is also available for synched Realms. However, note that if you supply an encryption key to the SyncConfiguration only the local file is encrypted, not the file on the server or other devices. You would need to supply the encryption on each of these as well.
This also means that it is possible for one device to encrypt the data and send them to a device that saves them unencrypted.
On the wire we use TLS if you enabled it (which you should).
I want to setup the data encryption on SQL Server 2008 R2 Standard edition at database level. I already tried TDE but it is not available in Standard edition.
What can be the most efficient way of data encryption at database level in SQL Server 2008 R2 Standard edition?
With Standard Edition, there are several things you can do to encrypt data
EFS is a windows feature that can be used to encrypt the contents of files or folders using a certificate installed on the server. Be sure to test this on a non production system before impelementing and that the certificate is safely backed up.
Column level encryption can be implemented to protect the data
You can use Bitlocker to encrypt drives on your server to prevent low level attacks or data theft.
With 2008 R2 Enterprise, there are some additional methods to address encryption
TDE is one you already mentioned, so I'm sure you are familiar with this option
EKM stands for Extensible Key Management system and it can be an expansion card or separate hardware with a high speed interface that offloads the storage of keys and encryption and decryption functions. It can be managed by a separate team that the DBA for effective separation of duties.
As an example, I am planning to host a Redis database with persistence on a server. To protect the data on the disk, I think, I have two options: A) Do read/write operations via an encryption layer. B) Apply Full Disk Encryption (FDE) and let Redis to read/write as usual.
What are the pros and cons of the both the approaches above? What factors should I consider?
There seems to be some similarity here Database encryption or application level encryption? It is about db and application level encryption; but, my question is about the disk and an application (such as a db) level.
I was wondering what is the way for the FILESTREAM data encryption (for example .docx files) in SQL Server? Is it Microsoft EFS or there is another solution?
Thanks in advance
As far as I'm aware, there's no encryption built into the FILESTREAM feature. I would generally expect the application fronting the database to handle any encryption of the data before sending it to the database and decrypting after retrieval.
"Is it Microsoft EFS or there is another solution?"
Since you asked about other solutions as well, there are two third party products that offer alternatives to TDE including FileStream encryption. They both work with all versions and editions of SQL Server. One is NetLib Encryptionizer for SQL Server and the other is DBDefence. Although they both work differently. Encryptionizer sits between SQL Server and the OS, while DBDefence injects code into the running SQL process using the (now defunct) Detours SDK. (Disclaimer: I am with NetLib Security).
I'm looking for a distributed hash table to store and retrieve values securely. These are my requirements:
It must use an existing popular p2p network (I must guarantee my key/value will be stored and kept in multiple peers).
None but myself should be able to edit or delete the key/value. Ideally an encryption key that only I have access to would be required to edit my key value.
All peers would be able to read the key value (read-only access, only the key holder would be able to edit the value)
Is there such p2p distributed hash table?
Would the bittorrent distributed hash table meet my requirements?'
Where could I find documentation?
You don't need encryption, you need signatures.
The mainline bittorrent DHT does not allow arbitrary key value storage at the moment, only key -> IP:Port storage where the IP is fixed to the originator of the storage request. The vuze DHT on the other hand does support binary blob storage, on top of which you could implement some signature scheme.
Update: BEP44 added signed or hash-based key-value storage to the bittorrent DHT. But it imposes some restrictions what can be used as keys to randomly distribute data throughout the keyspace.