[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 |
-----BEGIN PGP SIGNED MESSAGE-----
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
identifiers...
> 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
that.
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 <<<<
$syllables="er,in,tia,wol,fe,pre,vet,jo,nes,al,len,son,cha,ir,ler,bo,ok,tio,nar,sim,ple,bla,ten,toe,cho,co,lat,spe,ak,er,po,co,lor,pen,cil,li,ght,wh,at,the,he,ck,is,mam,bo,no,f
i,ve,any,way,pol,iti,cs,ra,dio,sou,rce,sea,rch,pa,per,com,bo,sp,eak,st,fi,rst,gr,oup,boy,ea,gle,tr,ail,bi,ble,brb,pri,dee,kay,en,be,se";
$syllable_array=explode(",", $syllables);
srand((double)microtime()*1000000);
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
"0B0C955A9196DAF1D55F6E337FD93DC75FE8B488".
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE/cIlj9tNtMeXQLkIRAsL+AJ97S+fOInTGX9U+2ga2OJviu48ZbwCfZ8L+
PdEsNr7dm5fvPC8vNzF6B7M=
=VbaV
-----END PGP SIGNATURE-----