Re: [cryptography] How much does it cost to start a root CA ?
Correct. The cost of being CA is equal to the cost of getting CA signing pub key into the target audience browsers. You can (sorted by increasing security, starting with zero): 1 - go through browser vendors, 2 - have your users to install additional CA key into their existing browsers (and perhaps remove others), or 3 - distribute your own browser package. Pick one. > The policies are set by the browsers/root store operators - > not CAs. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
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
As long as each encryption of the same plaintext yields the same ciphertext, indexing works. However, the space is tight - plaintext size is close to the cipher capacity. BTW, the same plaintext is never encrypted with different keys, so CRT doesn't work. > Do you do any padding? If not you might be vulnerable > to multiplication because: > > RSA(a)*RSA(b) == RSA(a*b) > > and if you are doing padding (eg with random inputs if any > seeded by the > plaintext and a fixed secrete seed), then you need > rigorously verify the > padding on decrypt or the padding may not defend against > multiplication. ___ 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 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] Duplicate primes in lots of RSA moduli
Properly designed rngs should refuse to supply bits that have less than specified (nominal) entropy. The requestor can go away or wait. In many applications it is sufficient to postpone key generation until the last possible moment (for some odd reason, coders tend to generate keys first, then do everything else.) If that is not enough, you simply wait while entertaining the user with blinking lights. For example, clock-strobing in desktops can produce 3-5 bits/sec. That's 5 minutes just for a decent session (symmetric) key, and more for RSA. Of course, one can always choose to live with shitty keys. What recent events are showing is that the average effective key length is determined by rngs, and based on the results, it seems to be around 30-40 bits. > to increase entropy. You're supposed to have sufficient > entropy in the first place. ___ 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] philosophical question about strengths and attacks at impossible levels
It's because cryptographers don't really have more imagination than, say, TV screen OEMs: bigger is better, simply because they don't know to do anything else. It doesn't matter that there is no bandwidth to fill that screen, that there is really no content worth watching, that the effective angular size of pixel is getting bigger ... they keep making 'em bigger. Adding few bits of effective key length to 100+ bit key will get your paper published. Is it easy? No. Does it matter? It doesn't. > What if a hash has 512-bit collision-resistance? What would > that mean? > That an attacker might spend about 2^512 resources to find > ___ 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
