On Wed, Sep 23, 2009 at 10:43:11PM +0200, Michael Prinzinger wrote:

> I am trying to establish a routing path for an anonymity protocol (
> http://en.wikipedia.org/wiki/Phantom_Anonymity_Protocol).
> This is a one way procedure: the node that wants to be anonymized selects a
> couple of other nodes and sends an array with setup packages (encrypted with
> the node's public key) to the first node, it had selectd.
> 
> Now every such node accepts an anonymous connection from a client,
> receives this array,
> decrypts the setup package meant for this node,
> and finds inside: IP and Certificate of the previous and next node (and some
> more information unrelated to openssl).

"Certificates" are useless without corresponding signed messages. What
messages are signed by the private key of the "previous" node, that the
current node can forward to the next?

> When establishing a connection to the next node, the current node can thus
> verify the certificate of the next node.

Sure.

> However, now that the current node also got to know the previous node's
> certificate in a secure way, it can also verify the previous node's
> certificate.

This makes no sense. What message associated with the previous node do
you need to authenticate? Note, the SSL handshake involves the current
client signing the SSL handshake, and the certificate binds the client's
identity to that signature.

Why do you need client identity in an anonymity protocol? What is the
security role of the "previous" node certificate.

You are very confused about the requirements. Forget APIs, and programming
approaches for now, arrive a sensible protocol description. What is the
multi-hop protocol and how/why do you plan to secure it with assymetric
cryptography?

-- 
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    openssl-users@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to