[Top][All Lists]

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

Re: [GNUnet-developers] Re: URI suggestion

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Re: URI suggestion
Date: Tue, 23 Sep 2003 12:56:51 -0500
User-agent: KMail/1.4.3

Hash: SHA1

On Monday 22 September 2003 07:25 pm, Glenn McGrath wrote:
> On Mon, 22 Sep 2003 21:45:09 +0300 (EEST)
> Igor Wronsky <address@hidden> wrote:
> > Another thing that would be of practical value would
> > be the possibility to address a namespace by just a
> > human-readable pseudonym. I couldn't come up with a
> > neat crypto trick for that yet, but atleast it should
> > be kludgable.
> An optional alias could be attached somehow to the namespace, the
> obvious concern is collisions, i.e. two seperate namesapces want to use
> the same alias.

Right.  The key question is who is allowed to put forward that association.  
If I can insert a global handle for my own namespace, I could (maliciously) 
pick the alias of someone else who is popular and try to impersonate that 
pseudonym. For users that use the aliases (and that don't see the underlying 
public keys), this attack would succeed.  GNUnet could not tell which was the 
"original" alias / handle and prevent it.

> Alias wouldnt be the primary identifier, so collisions wouldnt be a
> problem.

If they are to be useful for the end-users, they'd likely become the primary 

> Handle it the same way instant messangers do it.

Eh, don't they just assume that the "first" person to take an alias gets to 
keep it? In a distributed P2P setting (IMs are centralized!), we can't do 

I have another idea. Why not *generate* shorter aliases from the public key.  
That is, you can not pick your alias, but there is a (deterministic) 
projection from your public key / pseudonym ID to a slightly more readable 
string.  An adversary that would want to take over a pseudonym would then 
have to find a public key that computes to a pseudonym ID that collides with 
the target ID.  Ok, given that the strings are likely to have less than 160 
bits of information, computing that collision may be *easier* than getting a 
collision on the RIPE160MD hash, but we could pick the IDs long enough to 
make it reasonably difficult.

I have some example PHP code that computes "almost natural language" passwords 
in the same way that I picture us computing more natural pseudonym aliases:

>>>> from BNT <<<<  
  $syllable_array=explode(",", $syllables);
  for ($count=1;$count<=4;$count++) {
    if (rand()%10 == 1) {
      $makepass .= sprintf("%0.0f",(rand()%50)+1);
    } else {
      $makepass .= sprintf("%s",$syllable_array[rand()%62]);   

Replace the PRNG with the hash (or initialize it with the hash), avoid 
duplicate syllables and this one gives you 32 bit aliases. Changing 4 to say 
6 gives use 48 bit which should be sufficiently collision resistant 
(considering that each test requires computing an RSA public/private key pair 
and that the adversary typically wants to force a collision with a specific 
pseudonym).  The resulting aliases woudl look like "ralenerdeekayse", which 
is probably easier for our brains to associate with values like "good 
content" or "garbage" than the currently used 

Version: GnuPG v1.0.7 (GNU/Linux)


reply via email to

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