Prev: What are the best steganalysis programs?
Next: How long to trust 3DES
From: Joseph Ashwood on 13 Apr 2006 23:51
<kevin.tambascio(a)gmail.com> wrote in message
news:1144946455.433740.288330(a)v46g2000cwv.googlegroups.com...
> The result we are seeing, is that once in a while the resulting cipher
> data length is 127 bytes, using OpenSSL's RSA encrypt routine. Most of
> the time, we are seeing 128 bytes as the length of the cipher data.
> The plain data is 20 bytes, it is a SHA-1 hash of another piece of
> data. Our e is currently 6553[7] (0x10001), which is what OpenSSL
> currently uses.

Yeah, you should see that about 1/256 of the time (changing a bit depending
on N). Even the occassional 120-byte (will happen on average about 1/2^64
times) value is acceptable. Unruh was referring to the case where you have a
diminutive message, so the exponentiation never wraps (which is extremely
dangerous).
Joe


From: kevin.tambascio@gmail.com on 27 Apr 2006 23:39
Are there any standalone implementations of OAEP and/or PSS that we
could use on top of BigDigits? I don't believe BigDigits supports
either of these padding schemes natively.

Regards.

From: tomstdenis on 28 Apr 2006 00:09

kevin.tambascio(a)gmail.com wrote:
> Are there any standalone implementations of OAEP and/or PSS that we
> could use on top of BigDigits? I don't believe BigDigits supports
> either of these padding schemes natively.

I seriously doubt BigDigits [whatever that is] has any sort of
performance advantage over OpenSSL. OpenSSL also performs proper [well
better] padding than raw RSA.

So your big hangup with using BigDigits is?

Tom

First  |  Prev  | 
Pages: 1 2
Prev: What are the best steganalysis programs?
Next: How long to trust 3DES