[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] gnunet-peer-info/host keys

From: Jan Marco Alkema
Subject: [GNUnet-developers] gnunet-peer-info/host keys
Date: Sun, 16 Feb 2003 16:10:21 -0800

Hello Christian, Igor, Glenn,

At the moment I am porting gnunet-peer-info to ODBC for experimental use. I
want to put the host keys in ODBC by translating it to hexa code. The host
key files have a size of 564 bytes. That will result in 1128 characters in
ODBC. One's the host keys are in the ODBC database they are accessible to

If ODBC works I will make it possible to query in JDBC (simple java client).
After this I want to try PHP to put the Host keys in a PHP environment via
ODBC. See appendix A for a PHP/ODBC example.

I have ported the concept of  "distribution" in relation to "release" in the
key environment in mine mind. 1 host key is for identifying your gnunetd
system. It has a long expiration timeline (a year or much longer)  and you
can see it as the GUID of the gnunet system. If you look in time the GUID
("distribution") uses a lot of host keys ("following releases") with limited
timeline. Before they can hack it there will be a new hostkey.

Some information about GUID from Internet:
"In Microsoft Windows 2000, each security principal (user, group, or
computer) is identified by a unique security identifier (SID) in the form of
a The globally unique identifier GUID. In Active Directory directory
service, each object has a distinguished name. works by assigning each browser a unique, essentially random
16-byte user ID, which is represented as 32 hexadecimal digits. This ID is
constructed by applying a MD5 hash to a string concatenated from the IP
address of the requestor, the IP address of this server, the date, and the
time of day in ticks. The ID is then set as a cookie from"

For example you have 5 peers: Peer_A, Peer_B, Peer_C, Peer_D and Peer_E. If
you look from peer_C to the others. Peer_C gives the public key to Peer_A,
Peer_B, Peer_D and Peer_E. Peer_C will keep the secret key strongly privat.
If peer_B encrypts with the public key the next message "Tranfer 25 dollar
from the bank account (GUID_B) of Peer_B to the bank account (GUID_D) of
Peer_D". Only Peer_C can read this message by using the secret key. The only
problem is that the same messages can be encrypted by Peer_A. Peer_C can not
validate that the sender is Peer_B. Everyone who has the public key can
encrypt this message.

Solution: Peer_C gives all other peers (Peer_A, Peer_B, Peer_D and Peer_E) a
different unique "public key". N.B. Unique "public key" Peer_A is only
available for Peer_A.

Peer_C has four key databases.
1: Secret keys (in Gnunet: .hostkey) ;
2: Secret keys of the unique "public keys";
2: Unique "public key" of all other nodes only available for the node it
depends on;
3: Public keys of the other nodes (available for everyone) including the
Public key of Peer_C.

If someone has better ideas please let me know ---),

Greeting Jan Marco

Appendix A: PHP/ODBC example:

    // create connection
    $connection = odbc_connect("YourDataSourceName","username","password");

    // test connection
    if (!$connection) {
        echo "Couldn't make a connection!";

    // create SQL statement

    // prepare SQL statement
    $sql_result = odbc_prepare($connection,$sql);

    // execute SQL statement and get results

    // format result in HTML table

    // free resources and close connection


reply via email to

[Prev in Thread] Current Thread [Next in Thread]