Re: RSA padding
From: Michael Amling (nospam_at_nospam.com)
Date: 12/08/03
- Next message: Vincent Quesnoit: "Re: OTP ciphertext analysis?"
- Previous message: Michael Amling: "Re: Need short GUID for file identifiers"
- In reply to: Tim Smith: "Re: RSA padding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 08 Dec 2003 15:15:17 GMT
Tim Smith wrote:
> In article <br104v$4c8$1@agate.berkeley.edu>, David Wagner wrote:
>
>>>I'm curious how good or bad something like this would be with RSA:
>>
>>Well, I don't like it much, myself. It has no integrity protection,
>>and I worry about chosen-ciphertext attacks. I prefer OAEP.
>
>
> I was assuming integrity protection as part of the message, but forgot to
> specify that.
>
>
>>Out of curiosity, why do you ask about this scheme?
>
>
> It just came up while thinking about ways to try to use RSA without too much
> risk. Here's the problem I'm trying to solve:
>
> I've got two operations I need to support:
>
> 1. When a user creates a new account, send their password to the server.
>
> 2. When a user logs in, verify that they know the password.
>
> For # 2, what I've been using is this:
>
> 1. Server sends a random byte string to client. (Obtained from
> /dev/urandom on Linux, which is the only platform the server runs on).
>
> 2. Client encrypts the byte string using twofish, sends result back.
>
> 3. Server decrypts and sees if strings match.
Have you looked at SRP? IIRC, you can implement it using just a
multi-precision library. See http://srp.stanford.edu/ or RFC 2945.
IIRC, the SRP sign-in process also produces a shared secret as a side
effect, suitable for generating session keys.
>
> For #1, what I've been using is this:
>
> 1. Client prepends message string with length (in printf %d format) and
> a colon, pads it to 63 bytes with psuedorandom numbers using whatever
> PRNG is provided by the compiler's library, and encrypts using a 512-bit
> RSA modulus (yeah, I know it should be bigger...I'll address that in the
> revision I'm doing of this) (these are passwords for a chat system, and
> from what I've seen, ROT-13 would be good enough security considering
> how obvious most of the passwords are, so mostly I just want to make
> this better so that ages from now, if this code ever ends up getting
> reused somewhere where good security IS needed, it will be OK).
If you were to implement SRP, the client would use this procedure to
send the verifier, not the password.
With SRP, sniffing the traffic on the network does not give Eve
sufficient information to conduct an offline dictionary attack on the
password.
>
> 2. Server decrypts to get the password.
>
> A couple problems have arose. I have a need to write some special clients
> in Perl and Java. For Perl, some of them will be run on Windows versions of
> Perl which the people using are having trouble installing modules from CPAN
> for some reason (and I'm not being helpful for them--I tell them to switch
> to Linux where Perl works fine :-)). For Java, some of the client have to
> work on old Microsoft versions that predate the cool crypto stuff. The
> clients also all need to be able to be used as part of proprietary products,
> so I can't use GPL'ed code.
>
> So, basically, I want something I can personally implement in C++, Perl, and
> Java, not using any add-on libraries. Somewhat surprisingly, MP math seems
> to be available everywhere: GMP on the server (GPL is OK there); I've got a
> less efficient MP library in C++ I wrote years ago that is good enough for
> this that I can use in the C++ Windows client; and Java and Perl both have
> MP libraries standard. Hence, the interest in RSA.
>
--Mike Amling
- Next message: Vincent Quesnoit: "Re: OTP ciphertext analysis?"
- Previous message: Michael Amling: "Re: Need short GUID for file identifiers"
- In reply to: Tim Smith: "Re: RSA padding"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
