Re: Encryption scheme using RSA

On Jan 11, 2:55 pm, gianluca.orte...@xxxxxxx wrote:
OK, but can you detail your "totally flawed" in some points (except
for the private/public mistake)? for example, in which ways could an
attacker break this schema?

About the alternative solutions, the decision is not completely up to
me. Otherwise I would have enthusiastically embraced an SSL or SSH
solution.

gianluca

First of all - there was no definition of the scheme, just some
mumbling that only give very vague idea about what you want to do. But
even from that it is clear to see that many active attacks (with man
in the middle) break the scheme completely. (f.e. attacker pretends to
be a server and after one single answer from your client, attacker
already knows everything about how to authenticate him/her self to a
real server).
Even if we forget about the most devastating attack on your "protocol"
when attacker is able to intersect communication between client and
server and replace server's public key with attackers' own public key
- you still have lots of extra openings for new attack on your
protocol. Take for example your "reversible obfuscation of the
password". How do you "encrypt reversibly obfuscated" password? Is it
RSA encrypted or RSA enveloped? If it is RSA encrypted, what padding
scheme you use? If you use good padding - what is the reason for you
"reversible obfuscation of password"? Your obfuscation can not improve
security of your protocol, but it can however introduce a lot of
weaknesses! Since it is reversible you have to assume that algorithm
is known to attacker (see Auguste Kerckhoff's 6 rules of secure system
design that he expressed in 1883!). That means that control over "a
random number that is sent from server" gives attacker possibility to
do lots of extra bits twigging and open lots of new vectors of
attack.
What you wrote was not(!) in any way description of secure protocol.
You want to see how secure protocol is described - check definition of
standard security protocols! But remember that even with these
protocols, lots of things are still omitted from the description (such
as some security proofs and assumptions), but assumes familiarity with
articles referred from the standard protocol description.

-Valery
.

Relevant Pages

  • Re: Where do the random numbers come from?
    ... Which part of the protocol is too slow? ... Diffie-Hellman key exchange is too slow for you, ... key exchange so that an attacker can't fake it. ... the best-known random number generator used for non- ...
    (comp.security.ssh)
  • Re: Where do the random numbers come from?
    ... I'll look into ssh... ... >>just using an established protocol is that resources on my client are ... > the server is convinced of your identity, a malicious attacker in ... >>Of course you can seed the BouncyCastle random number generator with ...
    (comp.security.ssh)
  • NetBSD Security Advisory 2003-006: Cryptographic weaknesses in Kerberos v4 protocol
    ... A cryptographic weakness in version 4 of the Kerberos protocol allows ... principal in a realm. ... An attacker controlling a krb4 shared cross-realm key can ... This attack may be performed against cross-realm principals, ...
    (Bugtraq)
  • [Full-Disclosure] NetBSD Security Advisory 2003-006: Cryptographic weaknesses in Kerberos v4 protoco
    ... A cryptographic weakness in version 4 of the Kerberos protocol allows ... principal in a realm. ... An attacker controlling a krb4 shared cross-realm key can ... This attack may be performed against cross-realm principals, ...
    (Full-Disclosure)
  • Re: Authentication
    ... I think trying to invent this kind of protocol on your own is too ... keys, i.e., that if you pick a public key by picking bits at random, ... an attacker can break this scheme by spoofing A. ... I hope this is enough to convince you that design of these protocols ...
    (sci.crypt)