rsa implementation question

Sam Holden sholden at flexal.cs.usyd.edu.au
Wed Aug 11 03:56:38 EDT 2004


On Wed, 11 Aug 2004 17:17:15 +1000, Ajay Brar <abra9823 at mail.usyd.edu.au> wrote:
> thanks
> i am using RSa for signing documents and hence decrypting and then 
> encrypting to verify?
>  what i was rather trying to get at was what if the plaintext is too 
> large? if the plaintext is greater than (log2 n)/8, would you just throw 
> an error or would you break the plaintext in parts.
> the reason i am asking this is because i am timing the sign operations 
> using the pcrypto package. the time is constant relative to the size of 
> the plaintext (as you would expect) but at a certain point there is an 
> increase in the time taken to sign. this corresponds to a very large 
> plaintext.
> that is why i was wondering about the  block thing.

If there is a sudden increase then in time then chances are you just
hit a cache barrier - the size before the increase fit into a
cache of some form (be it L1, L2, main memory, disk, etc) but the size
after the increase doesn't and hence you hit L2, main memory, disk,
network, etc. 

Of course that's just a general observation I know nothing about the
workings of RSA (well I did implement it once, but that was *long* ago).

Whenever I've done signing with say GnuPG of largish items (such
as tarballs of code) I generate an MD5 sum of the item and then
sign that, giving something like:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

9272bee983085f56aa830ae909f9b8dc  pywily.tgz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9j+tH/cbVr+0UoYRAn3OAJ0bMW3HbbXsuFGZ7H9DK5iMLpBDtwCgkSvB
Dj03m5eKTODAA6OKQc34HG4=
=52FO
-----END PGP SIGNATURE-----

I've never actually cared enough to investigate whether that
significantly reduces the security. A smarter person would include the
filesize in the signed portion especially since you can append to tgz
files to generate the MD5 sum you want for your replacement
pywily.tgz...

[snip a full-quote... is that acceptable around these parts?]

-- 
Sam Holden



More information about the Python-list mailing list