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
