whether there are adequate ways to make the encryption / decryption of files using several different keys? That is, it is possible to make a group of n keys so that any of the group key could encrypt file and also with any of the group key to decrypt the file? (Of course, provided that no other key, in addition to these n group keys to decrypt the file could not be?)
There isn't a way to encrypt with only one key, and be able to decrypt with several other keys individually.
You could have a group key that is encrypted by several keys, so those keys can decrypt the group key as needed, and the group key can be used to encrypt/decrypt data that is shared between users with different keys.
You could do the same thing with the data itself, but this means all keys need to be available for encryption, which doesn't seem to meet your use case.
Related
I want to query encrypted data from my SQLite database.
For each row, I'm using XOR operation on every value, convert it toBase64 and then INSERT it in the database.
Now I need to find a way to SELECT the encrypted values.
i.e:
SELECT *
FROM table
WHERE name_column BETWEEN 'value1' AND 'value2'
Considering the huge information in my database, how can I do that without having to decrypt all the table to get the wanted rows?
It's impossible. You are using BETWEEN 'value1' AND 'value2'. The database can only see the XORed strings and BETWEEN will not work as expected. Even if you find a way to decrypt the strings on-the-fly with SQLITE (remember XOR calling again will decrypt) it's not very efficient and resource consuming when there are thousand of entries.
So in order to continue with your problem you could have a look at this extension list. SQLITE seems to provide some very basic encryption modules, which can XOR the whole database with a key you defined. (not recommended)
This file describes the SQLite Encryption Extension (SEE) for SQLite.
The SEE allows SQLite to read and write encrypted database files. All
database content, including the metadata, is encrypted so that to an
outside observer the database appears to be white noise.
This file contains the complete source code to the SEE variant that
does weak XOR encryption. Do not take this file seriously. It is for
demonstration purposes only. XOR encryption is so weak that it hardly
qualifies as "encryption".
The way you want to do it won't work, unless you read all values of a column to your Qt program, decrypt them and check if VALUE X is BETWEEN A and B.
I am developing a application where the idea is to combine two separate keys into a single key. From my research there exists two common ways to do this:
1) Use concatenation of hashes and perhaps hash again
2) Use HMAC
Which would be the more secure approach, and if possible is there any source that could be used to back a specific approach?
Normally, the 2 keys are XOR'ed together to compute the final key
I am new to dynamodb (ddb). I was going through its documentation and it says to add Hash Key and a Hash Range key. In the documentation it says that ddb will create an usorted index on the hash key and a sorted index on the hash range.
What is the purpose of having these 2 keys rather than just one key. Is it because the first key is used like :
A HashTable which contains :
key - range of keys for each value in the hash range
2nd HashTable
hash range key - Actual data value.
This would help segregate data and make lookup fast. But then why only 2 levels of HashMaps, I could do this for n number of layers and get the faster lookups.
Thank you in advance.
Q:"What is the purpose of having these 2 keys rather than just one key?"
In terms of the Data Model, the Hash Key allows you to uniquely identify a record from your table, and the Range Key can be optionally used to group and sort several records that are usually retrieved together. Example: If you are defining an Aggregate to store Order Items, the OrderId could be your Hash Key, and the OrderItemId the Range Key. You can find below a formal definition for the use of these two keys:
"Composite Hash Key with Range Key allows the developer to create a
primary key that is the composite of two attributes, a 'hash
attribute' and a 'range attribute.' When querying against a composite
key, the hash attribute needs to be uniquely matched but a range
operation can be specified for the range attribute: e.g. all orders
from Werner in the past 24 hours, or all games played by an individual
player in the past 24 hours." [VOGELS]
So the Range Key adds a grouping capability to the Data Model, however, the use of these two keys also have an implication on the Storage Model:
"Dynamo uses consistent hashing to partition its key space across its
replicas and to ensure uniform load distribution. A uniform key
distribution can help us achieve uniform load distribution assuming
the access distribution of keys is not highly skewed."
[DDB-SOSP2007]
Not only the Hash Key allows to uniquely identify the record, but also is the mechanism to ensure load distribution. The Range Key (when used) helps to indicate the records that will be mostly retrieved together, therefore, the storage can also be optimized for such need.
Q:"But then why only 2 levels of HashMaps? I could do this for n number of layers and get the faster lookups."
Having many layers of lookups will add exponential complexity to effectively run the database in a cluster environment , which is one of the most essential use cases for the majority of NOSQL databases. The database has to be highly available, failure-proof, effectively scalable, and still perform in a distributed environment.
"One of the key design requirements for Dynamo is that it must scale
incrementally. This requires a mechanism to dynamically partition the
data over the set of nodes (i.e., storage hosts) in the system.
Dynamo’s partitioning scheme relies on consistent hashing to
distribute the load across multiple storage hosts."[DDB-SOSP2007]
It is always a trade off, every single limitation that you see in NOSQL databases are most likely introduced by the storage model requirements. Although Relational Databases are very flexible in terms of data modeling they have several limitations when it comes to run in a distributed environment.
Choosing the correct keys to represent your data is one of the most critical aspects during your design process, and it directly impacts how much your application will perform, scale and cost.
Footnotes:
The Data Model is the model through which we perceive and manipulate our data. It describes how we interact with the data in the database [FOWLER]. In other words, it is how you abstract your data model, the way you group your entities, the attributes that you choose as primary keys, etc
The Storage Model describes how the database stores and manipulates the data internally [FOWLER]. Although you cannot control this directly, you can certainly optimize how the data is retrieved or written by knowing how the database works internally.
i have a vendor company doing work and i noticed a flaw in the api, at one point an ID is not hashed,
For security reasons i want to find out if at one point you can see the ID in plain text and at another point you can see it hashed,
Can you work out the key? to decrypt these automatically?
Also i am worried the same key is used for another part of the api which is hashed the whole way through in case they used the same key for this too!
I think I understand the concept of not having hot hashKeys so that you use all the partitions in provisioning throughput. But do UUID hashKeys do a better job of distributing across the partitions than numerically sequenced ones? In both cases is a hashcode generated from the key and that value used to assign to a partition? If so, how do the hashcodes from two strings like: "100444" and "100445" differ? Are they close?
"100444" and "100445" are not any more likely to be in the same partition than a completely different number, like "12345" for example. Think of a DynamoDB table as a big hash table, where the hash key of the table is the key into the hash table. The underlying hash table is organized by the hash of the key, not by the key itself. You'll find that numbers and strings (UUIDs) both distribute fine in DynamoDB in terms of their distribution across partitions.
UUIDs are useful in DynamoDB because sequential numbers are difficult to generate in a scalable way for primary keys. Random numbers work well for primary keys, but sequential values are hard to generate without gaps and in a way that scales to the level of throughput that you can provision in a DynamoDB table. When you insert new items into a DynamoDB table, you can use conditional writes to ensure an item doesn't already exist with that primary key value.
(Note: this question is also cross-posted in this AWS Forums post and discussed there as well).