Re: [cryptography] Questions about crypto in Oracle TDE
There is some space. But this is not the usual PK situation where 256-bit secret key is stuffed in 2000+ bit space. Few notes: - Data integrity/authenticity was not the objective. Only secrecy. - Obtaining 'public' key means subverting and reverse engineering the application input modules, and is equivalent in difficulty to finding secret database key in the classical approach. There is nothing public about this 'public' key. Whoever can randomly play chosen plaintext attacks already owns the application and the database. - Finding valid credit card numbers or SSNs which are multiples of others requires substantial luck. - Adversary that can derive RSA secret key from poorly-padded ciphertext with chosen plaintext attacks will know that it's cheaper to beat the shit out of sys admin to get all data. To conclude, this is not a generic/universal approach that is supposed to withstand all (un)imaginable attacks from resourceful adversaries. This is just a point solution for protecting certain database fields, that replaces secret key crypto with asymmetric crypto, and partitions the application in such way to minimize exposure of decrypting keys - modules that need plaintext can be kept far away from machines with public interfaces. It is not less secure than classical approach, and due to ratio of cipher size to data size it allows indexing. is there an inferred so we have no space to pad the plaintext there? BTW, the same plaintext is never encrypted with different keys, so CRT doesn't work. Well that maybe, but without padding RSA(a)*RSA(b) == RSA(a*b) so the attacker can create fake data or test values by using multiplication. eg values a,b,c,d, etc He can create new values k*a for any integer k (as encryption is public) RSA(k*a) = RSA(k)*RSA(a); he can test multiples.. RSA(b) =? RSA(k)*RSA(a) he can compare values with multiples of other values: RSA(c) =? RSA(a)*RSA(b) and any variation thereof. With some knowledge of the domain of the values, and given arbitrary known plaintext-ciphertext pairs (being public key crypto) thats a fair amount of rope for an attacker to play with. Not ECB, but its something else fragile with its own problems... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Questions about crypto in Oracle TDE
We have been using a different approach for securing particular fields in the database. The main issue with symmetric ciphers inside (distributed) systems is that the encrypting entity is always the most numerous weak point. Whoever subverts your input flow - and there are lots of opportunities there - gets keys to everything. Your distributed system is not really distributed - it's mostly distributing vulnerabilities. However, if you use asymmetric crypto (say, 1024 or 2048-bit RSA), give only public key(s) to encrypting flows, and reserve the secret key(s) for modules that need the actual plaintext access (a rare situation in practice), then: - the storage size remains the same; - you can use the first 512 bits or so for indexing (you may get a collision once before the Universe cools down, or whatever your belief about the curvature is.) - there are no ECB issues (for field sizes 1024 or 2048 bits, most are); - the extra CPU cost for modular arithmetic (to insert or search) is negligible (at least in use cases we've seen so far); - the security requirements on the input side drop down big time. You can (continue to) have bozos code your 'apps'. More philosophically, the database is just a wire with a delay. You would never directly use symmetric keys in other communications (by sharing them under the table), would you? --- On Thu, 11/8/12, Adam Back a...@cypherspace.org wrote: IMO this fixed IV for searchability/indexability crypto pattern is a common mistake. I prefer and consider it more secure to use a (keyed) MAC of the plaintext as the index, and then encrypt the plaintexts conventionally with a random IV. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] -currently available- crypto cards with onboard key storage
Take a cheap Android, write the code you need for it, make it talk via USB, rip out all antennas, put it in your box (wrap in a paper bag first), and connect with USB cable to the internal USB port. HW cost: $80 a Trojan. Security certification concerns put aside, the architectural demands are no more elaborate than a CPU unlikely to be infected by a Trojan. From there, you either pay for the certification gimmick, or you mend your own solution. This is the basis for an open source HSM ... cryptography mailing list ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Digital cash in the news...
BitCoin has only one problem: maintenance of the relationship between unit BitCoin value and the material world (energy, as in KWh) is 'soft', it requires some sort of a volatile communal effort, which sets it for failure (as a counter example, the amount of Au atoms on this planet is rather independent from any communal effort.) The relationship between unit value and the material world needs to be fixed. It's just a matter of time. Then we may name it ButtCoin. We expect money to be a store of value, among a few other things. BitCoin has nothing in it that speaks to that goal, that I can see [0]. This anti-property would however make it more ideal for a bubble [1]. Quite how to fix that and retain the decentralised control aspect, I'm unsure. The essence of a contract is that someone delivers something to someone else; without that first party (which speaks to centralisation at some level) it is hard. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] key management guidelines
The basic fallacy here is the assumption that some magical 'identity' exists and all we have to do is be brilliant enough to figure it out. It doesn't. It's just a collection of beneficial behaviors, a Nash equilibrium that changes as the rules of the Game change (which, by definition, exists :-) Identity will be something different in digital representations, and as we learn to cheat and catch cheaters and benefit from both, it will transform into something else again. It begins to sound biblical, but I AM is your inner identity bereft of name and ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
