gmane.network.gnunet.devel

GNUnet < at > Google Summer of Code

Bart Polot — 2013-04-11T13:48:04

Hi all GNUnet hackers!

Are you a student in any recognized university and are you interested in hacking 
on GNUnet and have Google pay you for it? Now it's possible! GNUnet is 
participating in the Google Summer of Code[1] under the GNU umbrella[2].


The Google Summer of Code gives you the opportunity to work on a GNUnet-
related *coding* project with one of the GNUnet developers as your mentor. The 
current ideas page is up [3] but feel free to suggest your own ideas!


- Go look at the Google Summer of Code FAQ [4] to make sure you are eligible to 
participate (basically, currently studiyng at any university outside of the US-
defined Axis of Evil). Important: if you are currenly working on GNUnet you STILL 
qualify to continue working on Google's bucks!
- Have a look at our ideas list [3] to see if one of those projects matches your 
interests.
- If there is no project on that list that you'd want to work on, read the 
documentation on our website [5] or our bug-tracker [6] (see various feature 
requests) and make up your own project idea!
- Come to #gnunet on Freenode or send an email to any mentor from the GNUnet 
ideas page and let us know about your project idea. Communication is essential 
to success in the summer of code, and we're unlikely to accept students we 
haven't heard from before reading their application. So really, come talk to us 
first!

Finally, write down your project idea and submit your application to Google until 
May 3, 2013 [7].

We are looking forward to discussing your project idea with you!

[1]https://www.google-melange.com/gsoc/homepage/google/gsoc2013
[2]https://www.google-melange.com/gsoc/org/google/gsoc2013/gnu
[3] https://gnunet.org/gsoc2013
[4] https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page
[5] https://gnunet.org/project-overview
[6] https://gnunet.org/bugs/main_page.php
[7] https://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/help_page#8.
_When_can_I_apply_for_Google_Summer_of
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

NS updates

LRN — 2013-02-26T12:28:47

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm looking at gnunet-fs-gtk core at the moment, and i don't get it.

It is my understanding that 'next_id' is simply an identifier, and its
presence in metadata indicates that GNUnet client should do a search
for that identifier, and any results should be considered 'updated'
versions of the original. Fairly straightforward.

add_updateable_to_ts() inserts "last_id" value it gets from the
iterator as PSEUDONYM_MC_LAST_ID, while setting PSEUDONYM_MC_NEXT_ID
to an empty string.

GNUNET_GTK_master_publish_dialog_execute_button_clicked_cb() gets
PSEUDONYM_MC_LAST_ID and PSEUDONYM_MC_NEXT_ID and uses them as
"identifier" and "update identifier" respectively.

When populating the treeview, PSEUDONYM_MC_CURRENT_ID_EDITABLE is set
to FALSE for all updateable items, it seems, and TRUE for all "empty"
rows (for new publications that do not update anything).
PSEUDONYM_MC_NEXT_ID_EDITABLE is always TRUE, no matter what.

But. GNUNET_FS_namespace_list_updateable () passes nsn->id as a second
callback argument (which becomes "last_id"), and nsn->update as a last
callback argument (which becomes "next_id").

So. fs-gtk pseudonym threeview seems to have four different item types:
1) "Blanks" - items for new publications, where you can edit both 'id'
and 'next_id'
2) "Leaves" - items for updates, where 'id' is frozen with the value
of 'next_id' from a previous publication, and 'next_id' is editable.
3) "Stems" - items that were inserted during the updateable items
graph walking. Their 'id' is frozen with the value of 'next_id' from a
previous publication, and 'next_id' is editable. They differ from the
leaves in that there already were updates to these items. Updating
them again will sprout more leaves (creating ambiguity, as one stem
will now have >1 possible updates instead of 0 or 1 updates).
4) "Root" - initial publication that started the update graph. Its
'id' is frozen with the value of 'id' (!) from the initial
publication, and 'next_id' is editable. Making "updates" with this
item will, in fact, produce a new publication with the same identifier
(thus increasing ambiguity, as one identifier will now yield multiple
items), and not update anything.

IMO (4) should not be in the list at all, why does
add_updateable_to_ts() add it? And the need of (3) is debatable as
well, since they break linearity of the update graph. If (3) is to be
offered, it should at least be indicated appropriately (to think of
it, (4) may remain in the tree as well, it just has to be unusable for
publications).
Do we _strive_ for linear update graphs at all?

It'd prefer to encourage users to maintain linear update graphs.
If someone wants branching graphs, we should offer a special widget
for that (you ever seen git commit trees in tutotirals? that's how
that special widget should look like, roughly).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRLKp+AAoJEOs4Jb6SI2CwtWgIANHV0qyepzKytSnpBycP9hbN
gohrabUHSfsq9KH6KOkWuXk8tU/8V2zAVYZ26LdxcAHbck50fmXmTyZSAbtpKNIY
xgjVnSOWOrcLAgC+eKygnRxsu0Q+KVsk6Q2mX3t/JNOi6AUYkVICZhO9Izf9KSU1
j3i0oVdsmG9qnoo74Vx9+FRkvSOf74uLB5Q+U8O9TOZOMSvRkO9EV87XLlFNAvut
tZg/IUkNAQi8HDqvlsrIMqcNGRRdqPIHOgTJsBXJ8Ww22xssSw+nrofHOTsOx0SJ
KPJ5g54uwAK5XfqF+gCOVMCG6RtSPGyt9VH3ljgSahzb66M8Aayh1pkJML1jU/8=
=uKtX
-----END PGP SIGNATURE-----

Namespace creation

LRN — 2013-02-16T12:50:14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Right now namespace creation is synchronous (RSA key is created
synchronously).

With the changes to IPC, it now may be possible to use async RSA key
creation securely, thus making namespace creation also asynchronous.

1) Should API users be exposed to key creation? Right now they have no
idea that namespace uses RSA internally (will it be switched to ECC at
some point?). However, if we expose key creation functions to the API
users, they will be able to create a key (synchronously or
asynchronously), and then (with a new FS API function) create a
namespace around that key. That way it will not be necessary to write
yet another namespace creation function that works asynchronously (it
will be synchronous instead; async key creation will be done by the FS
API user).

2) Should namespace creation API keep the "create always" behaviour?
Right now you can only give namespace a name (key is generated
internally), and if a namespace with that name already exists, the
exiting one will be returned immediately, making the whole thing opaque.
If API users are exposed to key generation, they may also take
advantage of more transparent namespace creation from generated keys.
FS API would fail to create a namespace if another namespace with the
same name exists, UI will let user pick a different name.

3) Should namespaces have user-provided names, or is it OK to generate
their names randomly? Is namespace name (as named by user at the
moment) exposed in advertisements by default? If it is, then maybe
using some kind of generated "Namespace-XXXXXXX" name initially would
be better.
Anyway, from UI point of view it's more convenient to generate things,
since no dialogs need to be shown.
The idea is that only one namespace will be used by default, and
initially one will have to be created. Showing the namespace
management dialog (which is relatively large and multi-functional) at
the initial UI startup may not be a good idea. Just generate a key,
pick a dummy name, and be done with it. And if namespace name is not
advertised by default, it doesn't matter what it's named, and since
most users won't have more than one namespace, they won't be confused
by naming anyway.

Something like that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRH4CFAAoJEOs4Jb6SI2CwmnMH/1Q41PvAI9YTZ9RMSiqcLj5h
e8yB3kUkWM8V+OSFGg+FyS48z5+x3Wlyo9HCsPFTw591jHN4JFs/7cj7pHkP55Ns
Bj62PPtuEab2ZmZTTkbQ0FPuqO0lswFaNe+PoE5DkZXHu6rL93CDlFsH8z/LtIBc
2oYLD8VyHQrni5IOC4C3rnnKo7jf/ce54lvTLCGthw5S2usstL+P7d/Kn3ki4NHF
K6SESKe5msNNw4Pr5gyh+KMFW2j5ZJTgkyizvUz28RTW48TPLFvrruvPUGdWH6jj
D2tiVZGS7dvE9Muv3j3eITfM3qxusfbs6uSqK3HVnqtTu4aiV8vilH7ojUzL76w=
=Zc1+
-----END PGP SIGNATURE-----

gnunet-java classloader issue

Smoratinos — 2013-02-09T11:14:16

Hello,

SVN revision 25955 fix a classloading issue from the Runabout class, but
there is the same problem with the MessageLoader class

Here is a patch : 

Index: src/org/gnunet/construct/MessageLoader.java
===================================================================
--- src/org/gnunet/construct/MessageLoader.java(révision 26052)
+++ src/org/gnunet/construct/MessageLoader.java(copie de travail)
< at >< at > -159,7 +159,7 < at >< at >
 
     < at >SuppressWarnings("unchecked")
     private static Class<? extends MessageUnion> loadClass(String
className) {
-        ClassLoader cl = ClassLoader.getSystemClassLoader();
+        ClassLoader cl =
Thread.currentThread().getContextClassLoader();
         Class<MessageUnion> msgClass;
         try {
             msgClass = (Class<MessageUnion>) cl.loadClass(className);


#############
This patch is needed by the GNUnetWebUI app.
https://gnunet.org/bugs/view.php?id=2769

Thank you


_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

FS - file uri max size

Smoratinos — 2013-02-08T19:28:29

Hello,

I study a solution to fix the issue gnunet-webui 0002765: length URI
search result 
https://gnunet.org/bugs/view.php?id=2765

What is the max size of the URI on a search result ?

GNUnetWebUI website

Smoratinos — 2013-02-01T23:31:51

Hello,

The GNUnetWebUI website is up.
http://gnunetwebui.site44.com

It's a prototype.
It isn't GNUnet website replacement, it is the future
website dedicated only to the GnunetWebUI subproject.

The hosting solution is temporary (dropbox + site.44.com).

It use static content, angular.js javascript library
and bootstrap twitter css library. 
The source code is open : 
https://gitorious.org/gnunet-webui/gnunet-webui-site

The GNUnet-logo was too little and I didn't find it with a
big enough resolution, that's why I use a different logo.
It is based on the "Joseph W. Reiss GNU head"
http://www.gnu.org/graphics/reiss-gnuhead.html

I have made some others logo, with different colors, 
if you are interested, tell me :) 

I am working on a web page, which details 
the project strategy.

All comments are welcome !

GNUnet 0.9.5 released

Christian Grothoff — 2012-12-21T18:43:27

Dear all,


We are pleased to announce the release of GNUnet 0.9.5. This release
focuses on fixing various bugs, but also includes for the first time
non-anonymous multi-hope file transfers using the stream and mesh
subsystems that were refined in the previous versions.  We also improved
some performance aspects and improved the graphical user interfaces (in
particular gnunet-setup and gnunet-fs-gtk).  As far as we know, this
release is fully protocol-compatible with GNUnet 0.9.4.


About GNUnet
============


GNUnet is a framework for secure peer-to-peer networking. GNUnet's
primary design goals are to protect the privacy of its users and to
guard itself against attacks or abuse. At this point, GNUnet offers two
primary applications on top of the framework:

The file-sharing service allows anonymous censorship-resistant
file-sharing. Files, searches and search results are encrypted to make
it hard to control, track or censor users. GNUnet's anonymity protocol
(gap) is designed to make it difficult to link users to their
file-sharing activities. Users can also individually trade-off between
performance and anonymity. Despite providing anonymity, GNUnet's
excess-based economy rewards contributing users with better performance.

The VPN service allows offering of hidden services within GNUnet (using
a .gnunet TLD) and can be used to tunnel IPv4 and IPv6 traffic over the
P2P network. The VPN can also be used for IP protocol translation
(6-to-4, 4-to-6) and it is possible to tunnel IP traffic over GNUnet
(6-over-4, 4-over-6).

The GNUnet Naming System (GNS) provides a fully-decentralized and
censorship resistant replacement for DNS. GNS can be used alongside DNS
and can be integrated with legacy applications (such as traditional
browsers) with moderate effort. GNS provides censorship-resistance,
memorable names and cryptographic integrity protection for the records.

Other applications are still under development.


Key features of GNUnet include:

* Works on GNU/Linux, FreeBSD, OS X and W32
* P2P communication over TCP, UDP, HTTP (IPv4 or IPv6) or WLAN
* Communication can be restricted to friends (F2F mode)
* Includes a general-purpose, secure distributed hash table

* NAT traversal using UPnP, ICMP or manual hole-punching (possibly in
combination with DynDNS)

* Small memory footprint (specifics depend on the configuration)

For developers, GNUnet offers:

* Access to all subsystems via clean C APIs
* Mostly written in C, but extensions possible in other languages
* Multi-process architecture for fault-isolation between components
* Use of event loop and processes instead of threads for ease of development
* Extensive logging and statistics facilities


* Integrated testing library for automatic deployment of large-scale
experiments with tens of thousands of peers


Noteworthy improvements in 0.9.5
================================

* non-anonymous multi-hope file transfers
* improved zone editing in gnunet-setup
* improved download user interface in gnunet-fs-gtk
* retired old testing library
* various improvements to APIs
* fixed incorrect display of probe results in gnunet-fs-gtk
* fixed various crashes and assertion failures
* CPU performance improvements in regular expression library
  (only relevant for complex exit policies, like 100k+ regexes)


Availability
============

The GNUnet 0.9.5 source code is available from all GNU FTP mirrors. The
GTK frontends (which includes the gnunet-setup tool) are a separate
download.

All known releases
    https://gnunet.org/current-downloads
GNUnet on a FTP mirror near you
    http://ftpmirror.gnu.org/gnunet/gnunet-0.9.5.tar.gz
GNUnet GTK on an FTP mirror near you
    http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.9.5.tar.gz
GNUnet on the primary GNU FTP server
    ftp://ftp.gnu.org/pub/gnu/gnunet/gnunet-0.9.5.tar.gz
GNUnet GTK on the primary GNU FTP server
    ftp://ftp.gnu.org/pub/gnu/gnunet/gnunet-gtk-0.9.5.tar.gz

Note that GNUnet is now started using "gnunet-arm -s"; the old gnunetd
binary is no more. GNUnet should be stopped using "gnunet-arm -e".

Further Information

GNUnet Homepage
    https://gnunet.org/
GNUnet Forum
    https://gnunet.org/forum
GNUnet Bug tracker
    https://gnunet.org/bugs/
IRC
    irc://irc.freenode.net/#gnunet


Thank you for your attention.

Happy hacking!


Christian Grothoff

Idea for file storage in GNUnet

hypothesys — 2012-12-06T21:03:03

Hello GNUnet Developers,

First of all I apologize if this is not the correct place for discussing a
possible new feature to GNUnet and since I am not from the IT field I cannot
even attempt to implement it. Still, perhaps if you find this feature
valuable you would consider implementing it so I wanted to share it. Please
bear in mind that I am no expert and this may not be feasible for technical
reasons not obvious to me. In that case please say so and I will not take
more of your time.

Some time ago I had the idea that gnunet (as well as other projects) could
benefit from increased disk space for storage and that using the free space
on disk should be a technically possible if difficult task.

On many OS filesystems, when a file is deleted, it is not truly erased, in
the FAT filesystem for example, the list of disk clusters occupied by the
file be erased from the file allocation table marking those sectors
available. On other filesystems I do not know how that is handled but, for
the sake of argument let's say that a header is instead applied to the file
indicating that the file portion of the hard disk is available to be
overwritten.

/header/ data block Nº1; /header/ data block Nº2; /header/ data block
Nº3;...

If gnunet was able to split the file data into data blocks (encrypted of
course) and subsequently delete the data, while keeping both a checksum for
the data block and record of its disk location, the free disk space of
computers on which gnunet was installed could be used for storage without
compromising normal functioning of said computer.

This program, perhaps to be named gnunet-str (storage) would at the moment
of storage of data, create a checksum for every encrypted data block and for
every "contiguous" data group, as follows:

/block1/block2/block3/block4/block5/block6/block7/block8...
=>checksum1/checksum2/checksum3/checksum4/...

but also

/block1/block2/block3/block4/block5/block6/block7/block8...=>checksum1+2/checksum3+4/checksum5+6/checksum7+8...

and also

/block1/block2/block3/block4/block5/block6/block7/block8...=>checksum1+2+3+4/checksum5+6+7+8/checksum9+10+11+12...

and continuing...

In this way, it would be possible to (quickly? - by going from the checksums
for the agglomerations of blocks to the individual blocks) ascertain which
data was corrupt (by usage of the main OS, or a disk defrag) and had to be
replaced. It would then signal to other GNUnet nodes "Of the data stored
only 70% (for example) is still not corrupted. I can share this 70% but give
me the 30% back, or new files to store in this space".

Such a solution would allow big amounts of storage - in theory, if all free
space in the the hard drive of host computer. Due to its nature it would not
be possible to rely on the data not being compromised without implementing
redundancy. If this gnunet-str made x copies of file y for example, the
probability of data corruption and loss could be greatly diminished.
Tahoe-Lafs and gnunet are based on this principle (although I could be wrong
as I'm no expert), redundancy of storage between multiple peers on the net.
If this redundancy could also be implemented locally, the total storage for
GNUnet would increase.

Alternatively to providing a greater amount of data storage, perhaps such a
feature could instead be used to boost GNUnet's efficiency as parts of a
file on a distant node could also be made available on more nodes
diminishing the distance between the "asking node" and the node who actually
has the file.

Do you think such a feature could be useful for GNUnet? Once again do not
hesitate to say this idea is unfeasible for some reason, I just shared it in
the hopes of it being useful to an improved gnunet.

Camouflage

LRN — 2012-11-24T12:56:43

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is the idea that i've been thinking on.
It should be possible for GNUnet node operator to hide the fact that
his machine runs a GNUnet node.

Ways to achieve this:

1) Fake HELLO messages.
AFAIU, right now anyone can collect HELLO messages (by running a node,
or by querying a hostlist server), and then claim (with certain degree
of sureness) that GNUnet nodes run on all addresses listed in these
messages. Companies that track torrent users do this for BitTorrent.
They may then proceed to actually connect to listed addresses to
verify them, but that is quite another story.
The solution is to spread fake HELLOs with fake public keys and fake
addresses.
A node should use its private key (key K) as a seed to generate a set
fake of addresses (set A). Then use K and A themselves to generate
fake public key (key F) for each A, thus getting a complete HELLO
message. The use of K as a seed ensures that the node will keep lying
about the same set of addresses (how large that set should be is an
open question) with the same keys, making the fakes more believable
(observer might think that these are real nodes, maintaining their
real HELLOs over time; failure to validate any of them might be blamed
on firewalls, etc).
Address sets will intersect (A1 and A2 generated from K1 and K2 may
share some elements), obviously, although that might not be true for
IPv6 addresses...
I expect that address generator will apply some rules to generate
believable addresses (i.e. don't generate invalid IP addresses, like
10.1.0.255).
As an extra, a node could validate generated addresses and do
non-agressive portscanning (or something similar - we're not speaking
only of tcp) on them, to be able to add ports (or other parts of the
address) that look believable to observers.

AFAIU, right now nodes won't gossip about fake HELLOs (i.e. a node
will never tell another node about a HELLO it got, unless it validated
that HELLO). That might need to be changed to allow nodes to choose a
random subset of invalid HELLOs and gossip about them as well.
Otherwise only the node that generated them will be able to spread them.
Not sure about hostlists.

Extra yummy feature - add user-configurable fake templates, which
could have addresses only, or addresses and private keys. GNUnet node
will use templates from time to time (configurable) instead of
generated addresses, and will generate missing template elements.
It would be neat to be able to tell the world that 65.55.58.201 [1]
runs a GNUnet http_server transport on port 80...

2) Transport disguise.
Modify the protocol to allow clients to ignore initial data sent by
the server, and require clients to be the first ones to speak GNUnet
protocol after connecting (i'm not sure how the protocol works right
now; what a GNUnet node sends to the connected party immediately after
accepting an incoming connection? Does it send anything at all?).
A node should send fake data that looks like, say, FTP greeting,
faking a real-life FTP server.
This will prevent casual observers from identifying the node as GNUnet
node.
Non-casual observer should not follow the fake protocol, but proceed
to send a normal GNUnet handshake.
If the node doesn't get a GNUnet handshake as a reply to its fake
greeting, it might either drop the connection, or use some kind of
bogus access control error as an excuse to drop it (i.e. ask for ftp
login/password combo, and then reject all such combos and drop
"clients" that failed to "authenticate" this way).

Or a node should simply remain silent until it gets incoming handshake
message.

3) Handshake-first protocol
Besides (2), which may or may not be implemented, don't identify
yourself as GNUnet node until incoming peer sends a handshake, then
drop it, if it doesn't match one of your friends, if you're running in
F2F-only mode. You will be able to hide the fact that you're a GNUnet
node, since only friends will get _anything_ out of you. Other
non-friend (normal or malicious) GNUnet clients will have their
connections dropped after their handshake message.

To make it work both ways, GNUnet should establish a generic session
with TLS encryption first. Again, it's not uncommon for services to
have ports on which clients are expected to connect with an SSL/TLS
session (instead of connecting normally and then issuing StartTLS).
The point here is to use common TLS certificates and TLS connections
for initial authentication (friend nodes will know TLS certificates of
each other in advance). Otherwise your node will not be able to
connect to any of your friends without revealing that it's a GNUnet
node (friend won't identify itself as a GNUnet node initially, until
you send a handshake, thus preventing you from verifying that you've
connected to your friend, not to some man in the middle; and if you
send a GNUnet handshake, you will reveal yourself as GNUnet node to
the other end of the connection, not knowing who might be there). TLS
allows authentication without revealing that nodes are using GNUnet.
And using TLS itself is, thankfully, not illegal yet (and, hopefully,
will never be).

This will have to be a separate transport, since

A) that is somewhat incompatible with existing tcp transport, which
does not rely in TLS at all, AFAIK.
B) Your friend might not be running in F2F-mode only, in which case
you will reveal that you run GNUnet by connecting to your friend on
the same port that other nodes connect to. If there's a separate port,
which only accepts TLSed sessions, and only accepts known friends on
them (at TLS level), it will be much more difficult for non-friends to
identify you. If you make a TLS connection on port A to a machine that
_also_ runs GNUnet on port B, that will not immediately prove that you
are running GNUnet in F2F-only mode.

We already discussed (3) in the past, AFAIR, just making sure that
this discussion sticks somewhere.




[1] That's what microsoft.com resolves to, for me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJQsMQKAAoJEOs4Jb6SI2Cwl+kH/3witTSFCo+AnfKVvp5Rgc4l
gOJxfH3EXp4UkuwVSQqbsnocknzRnb/nrvqgKZ/vukcQOKWtH1N8NxU8+MOHfUsH
cNkA2KojEvrFM4TlI4o5uSOM1/f8nyBiui5pqb4bxi8MVv47WwStX2WqCiziNxml
UcQwD/0yneoj3blV2DAKA7V09pccniX35GQpluB1WZcJoSGvqhYbYeEVigtrZFmu
lKDS32fZE104HGbrhksox1/wa+wPysk/174xOvCJOzQWCAWK8N31QZRUQphSlyvv
dyjIU77G/ftOjiNhgd1uskhAbKU7mZoDa6J52+Nc3+Gik8cIwJCgrYHG3kEP9ro=
=bqkM
-----END PGP SIGNATURE-----

Gnunet Web UI

SMoratinos — 2012-11-22T19:32:33

Hello,

I'm creating a new User Interface for my Gnunet server, a web user 
interface.

My Gnunet Node is running on a linux server with no X-server.
So a webUI is more user friendly than the shell command.

Right now, it's for my needs, but maybe are you interested in a webui ?
Before publishing something, I wanted your opinion.

This is some expected features :

* Web User Interface :
     - Standard client technologies HTML5 + CSS3 + Javascript.
     - Responsive web design, from desktop computer monitors to mobile 
phones

* Server Logic :
     - Java language

* Multi-User :
     - Access control, authorization, authentification

* Control Gnunet (via shell command) :
     - start stop arm and other service

* Read statistics (via gnunet-java) :
     - graphic, real time (websocket)

* File-Sharing (via shell because gnunet-java don't have fs) :
     - search, download, publish

* Administration :
     - modify configuration files

* External API :
     - REST, JSON + XML

* MultiPlatform/ MultiLanguage :
     - all platform, datastore, languages than Gnunet support,
        but at the beginning at least debian/postgresql/english.


I would share my project via Github on the beginning
  (because it's easy for me), but later I can change, naturally.

I planned to share my project (licence GPL like Gnunet),
  can I use the name GnunetWebUI ?

What do you think about this project ?

compilation of 0.9.4 on x64 opensuse doesnt follow proper lib(64) directory path names (tries /usr/local/lib/gnunet... instead of /usr/local/lib64/gnunet....)

sngh — 2012-11-09T01:05:56

compilation of 0.9.4 on x64 opensuse doesnt follow proper lib
directory path names (tries /usr/local/lib/gnunet... instead of
/usr/local/lib64/gnunet....)

just compiled 0.9.4 on x64 opensuse according to README

sudo -u gnunet gnunet-arm -s
gnunet's password:
Nov 09 02:00:16-370194 util-23964 WARNING `access' failed on file
`/usr/local/lib/gnunet/libexec/gnunet-service-arm' at
os_installation.c:652 with error: No such file or directory
Operation failed.
testuser< at >linux:~/Downloads/gnunet-0.9.4> ls /usr/local/lib
lib/   lib64/
testuser< at >linux:~/Downloads/gnunet-0.9.4> ls /usr/local/lib/gnunet
ls: cannot access /usr/local/lib/gnunet: No such file or directory
testuser< at >linux:~/Downloads/gnunet-0.9.4> ls /usr/local/lib64/gnunet
libexec                        libgnunet_plugin_block_mesh.la
libgnunet_plugin_datacache_template.so
libgnunet_plugin_transport_http_client.la
libgnunet_plugin_transport_tcp.so
libgnunet_plugin_block_dht.la  libgnunet_plugin_block_mesh.so
libgnunet_plugin_datastore_sqlite.la
libgnunet_plugin_transport_http_client.so
libgnunet_plugin_transport_template.la
libgnunet_plugin_block_dht.so  libgnunet_plugin_block_template.la
libgnunet_plugin_datastore_sqlite.so
libgnunet_plugin_transport_https_client.la
libgnunet_plugin_transport_template.so
libgnunet_plugin_block_dns.la  libgnunet_plugin_block_template.so
libgnunet_plugin_datastore_template.la
libgnunet_plugin_transport_https_client.so
libgnunet_plugin_transport_udp.la
libgnunet_plugin_block_dns.so  libgnunet_plugin_block_test.la
libgnunet_plugin_datastore_template.so
libgnunet_plugin_transport_http_server.la
libgnunet_plugin_transport_udp.so
libgnunet_plugin_block_fs.la   libgnunet_plugin_block_test.so
libgnunet_plugin_namestore_sqlite.la
libgnunet_plugin_transport_http_server.so
libgnunet_plugin_transport_unix.la
libgnunet_plugin_block_fs.so   libgnunet_plugin_datacache_sqlite.la
libgnunet_plugin_namestore_sqlite.so
libgnunet_plugin_transport_https_server.la
libgnunet_plugin_transport_unix.so
libgnunet_plugin_block_gns.la  libgnunet_plugin_datacache_sqlite.so
libgnunet_plugin_test.la
libgnunet_plugin_transport_https_server.so
libgnunet_plugin_transport_wlan.la
libgnunet_plugin_block_gns.so  libgnunet_plugin_datacache_template.la
libgnunet_plugin_test.so
libgnunet_plugin_transport_tcp.la
libgnunet_plugin_transport_wlan.so


too bad. :(
config files or something not lib64 proof?
this is currently opensuse-12.3-x64-milestone1

uname -a
Linux linux 3.6.3-8-desktop #1 SMP PREEMPT Sun Oct 21 22:15:08 UTC
2012 (c367f31) x86_64 x86_64 x86_64 GNU/Linux

few questions on opensuse (useradd, groupadd), also: where does LE_PREFIX come from?

sngh — 2012-11-09T00:12:41

Hello list,

reading through README from 0.9.4, building from source, having openSuse system


there is no addgroup or adduser on opensuse. there is groupadd, I
added a group called "gnunetdns"

/etc/group now has:
gnunetdns:!:1000:

What about the adduser command, I suppose thats an error in README,
should there be a user called "gnunet" added into the previously
created group "gnunetdns", or is that gnunetdns as the group name
false, and should the groups name also be gnunet, and the user gnunet
be a member of group gnunet?

With "usermod" I modded the user "gnunet" a bit:
id gnunet
uid=1001(gnunet) gid=1000(gnunetdns) groups=1000(gnunetdns),33(video),100(users)
so now I have a user called "gnunet" member of "gnunetdns" group. is
this according to the needs of the gnunet app?

Also, where is the LE_PREFIX defined? I have previously compiled
libextractor (1.0.1 or so) myself, I suppose LE stands for
libextractor, and that got itself installed into /usr/lib/ or so as
defaulted, but I dont have a variable name called LE_PREFIX (yet? does
the make and config scripts of gnunet sources give me that variable?)

Thanks for helping. Regards.

Propose new feature - Search Indexer WebServicefor GNUnet

SMoratinos — 2012-11-07T20:48:07

Hello Gnunet Developers,


I consider Gnunet for few days, firstly great work and thank you for 
the documentation. As Java developer, I could appreciate the gnunet-java 
api quality code.

I'm not familiar with P2P network, thanks for all your publications and 
talks, it's very interesting.

I propose a new feature, I hope to get feedback before I actually 
started development.
Don't hesitate to tell me if my idea is useless or bad.


-----------
Observations:

  - Research (file-sharing) on gnunet are not easy or not fast.
  - GNUnet doesn't propose research, I must know the keywords. 
Sometimes, I don't know what to look for?
  - I can't search when I'm disconnected from gnunet's network, for 
example from my smartphone.
  - I don't have notification, for new content ?

But what it lacks (in my opinion) in gnunet networks ? a Google-like 
for GNUnet. A webservice who indexes the search result for gnunet 
network.


-----------
What I propose:

I would like an alternative to gnunet's anonymous file search.
I would like a central public web interface as an alternative search.
GNUnet's users use the standard search gnunet-fs-search but if they 
wish to perform these searches via a central server they can. This is 
faster but the anonymity of the research is no longer guaranteed.

The idea is to have several web server dedicated to the research on 
gnunet's network. These servers can be specialized in one type of 
content, why not.
We can imagine friends, create a web server to reference a Search 
Indexer WebService for GNUnet Private F2F mode.
This enabled to have notifications of new content.
Example: I get a notification on my smartphone:
from: John
keyword: holydays_2012_10_nigeria, images, jpeg, album
uri: gnunet://fs/chk/........

This is only for the search not for the download.

-----------
Two methods:

  - The future web server "Search Indexer WebService for GNUnet" is 
connected to the network and indexes only GNUnet search results, 
non-optimal solution.
  - Or allows gnunet-publish (optional) to record information (chosen 
among keyword, namespace, etc ...) on a web server via a simple rest 
api, The server isn't connected to the gnunet's network. The best 
solution in my opinion.

This assumes that the user interfaces (gnunet-gtk, and other in the 
futur) allow this choice (make a http request to a given web url). 
Little development expected, I think.
This assumes that there exists a web search engine that indexes the 
content of gnunet and restore via the classic web. This is the "Search 
Indexer WebService for GNUnet". More development expected.

-----------
What I want to do:

As a Java developer, I'm interested in the design of such service, I 
don't ask for help in development (I don't refuse).


-----------
Result:

This enabled GNUnet open to the public, and beginners, who came from 
the web. This doesn't alter the GNUnet core, and doesn't affect the 
safety or anonymity of classic research for those who wish.


-----------
Feedback Wanted :

Do you find this interesting? Are you to promote this type of service 
or are you against it?
It feasibility in your opinion? What problems will I encounter?
Do you have any suggestions, ideas, advice?
Do I need to extend this service to other service that the 
file-sharing, for example for GNS?


P.S : sorry for my bad english ;)

typo in 0.9.4 announcement blogpost ongnunet.org

sngh — 2012-11-06T23:34:43

typo in 0.9.4 announcement blogpost on gnunet.org
<https://gnunet.org/gnunet-094>
speaks in the lower part of the text about 0.9.3 sources though.
shouldnt that read 0.9.4 sources?

GNUnet 0.9.4 released

Christian Grothoff — 2012-11-05T21:57:35

Dear all,

We are pleased to announce the release of GNUnet 0.9.4. This release 
brings a major rewrite of the MESH subsystem, resulting in significant 
performance and stability improvements and the ability to define EXIT 
policies for the GNUnet VPN. The release also includes an initial 
implementation of the GNU Alternative Domain System, a decentralized and 
censorship-resistant replacement for DNS. The HTTP and HTTPS transport 
plugins can now tunnel their traffic over a reverse proxy.  The release 
fixes various bugs and brings various API extensions and other minor 
improvements. Except for the MESH subsystem and the HTTP plugins, this 
release is largely protocol-compatible with GNUnet 0.9.3.


About GNUnet
============



GNUnet is a framework for secure peer-to-peer networking. GNUnet's 
primary design goals are to protect the privacy of its users and to 
guard itself against attacks or abuse. At this point, GNUnet offers two 
primary applications on top of the framework:

The file-sharing service allows anonymous censorship-resistant 
file-sharing. Files, searches and search results are encrypted to make 
it hard to control, track or censor users. GNUnet's anonymity protocol 
(gap) is designed to make it difficult to link users to their 
file-sharing activities. Users can also individually trade-off between 
performance and anonymity. Despite providing anonymity, GNUnet's 
excess-based economy rewards contributing users with better performance.

The VPN service allows offering of hidden services within GNUnet (using 
a .gnunet TLD) and can be used to tunnel IPv4 and IPv6 traffic over the 
P2P network. The VPN can also be used for IP protocol translation 
(6-to-4, 4-to-6) and it is possible to tunnel IP traffic over GNUnet 
(6-over-4, 4-over-6).

The GNUnet Naming System (GNS) provides a fully-decentralized and 
censorship resistant replacement for DNS. GNS can be used alongside DNS 
and can be integrated with legacy applications (such as traditional 
browsers) with moderate effort. GNS provides censorship-resistance, 
memorable names and cryptographic integrity protection for the records.

Other applications are still under development.


Key features of GNUnet include:

* Works on GNU/Linux, FreeBSD, OS X and W32
* P2P communication over TCP, UDP, HTTP (IPv4 or IPv6) or WLAN
* Communication can be restricted to friends (F2F mode)
* Includes a general-purpose, secure distributed hash table
* NAT traversal using UPnP, ICMP or manual hole-punching (possibly in 
combination with DynDNS)
* Small memory footprint (specifics depend on the configuration)

For developers, GNUnet offers:

* Access to all subsystems via clean C APIs
* Mostly written in C, but extensions possible in other languages
* Multi-process architecture for fault-isolation between components
* Use of event loop and processes instead of threads for ease of development
* Extensive logging and statistics facilities

* Integrated testing library for automatic deployment of large-scale 
experiments with tens of thousands of peers


Noteworthy improvements in 0.9.4
================================


* flow- and congestion-control for GNUnet's multicast subsystem
* support for exit policies and exit discovery for the GNUnet VPN
* support for reverse-proxies for HTTP and HTTPS transports
* GNUnet Naming System, an initial implementation of the GNU Alternative 
Domain System (GADS)
* gnunet-auto-share for automatically sharing a directory is available again
* gnunet-download now has a progress bar
* new API for ultra large-scale testing and benchmarking
* new API for reliable, ordered bidirectional communication between peers
* reductions in memory consumption (about 25%)
* performance improvements, especially on W32
* fixed excessive bandwidth consumption by UDP transport
* fixed incorrect peer address validation (transport subsystem)
* fixed overly restrictive default settings for access control in the 
configuration
* fixed various crashes (assertion failures, memory corruption, memory 
leaks, etc.)



Availability
============



The GNUnet 0.9.4 source code is available from all GNU FTP mirrors. The 
GTK frontends (which includes the gnunet-setup tool) are a separate 
download.

All known releases
     https://gnunet.org/current-downloads
GNUnet on a FTP mirror near you
     http://ftpmirror.gnu.org/gnunet/gnunet-0.9.4.tar.gz
GNUnet GTK on an FTP mirror near you
     http://ftpmirror.gnu.org/gnunet/gnunet-gtk-0.9.4.tar.gz
GNUnet on the primary GNU FTP server
     ftp://ftp.gnu.org/pub/gnu/gnunet/gnunet-0.9.4.tar.gz
GNUnet GTK on the primary GNU FTP server
     ftp://ftp.gnu.org/pub/gnu/gnunet/gnunet-gtk-0.9.4.tar.gz

Note that GNUnet is now started using "gnunet-arm -s"; the old gnunetd 
binary is no more. GNUnet should be stopped using "gnunet-arm -e".

Further Information

GNUnet Homepage
     https://gnunet.org/
GNUnet Forum
     https://gnunet.org/forum
GNUnet Bug tracker
     https://gnunet.org/bugs/
IRC
     irc://irc.freenode.net/#gnunet


Thank you for your attention.

Happy hacking!


Christian Grothoff

switch to a DVCS (Git)?

Ivan Shmakov — 2012-10-22T05:58:53

I wonder if there're plans to switch to a DVCS (such as Git, as
successfully used by a number of free software projects,
including those part of the GNU project), for GNUnet
development?

I mean, besides of a somewhat surprising situation of using a
centralized system to develop a decentralized one, Subversion is
a bit inconvenient in that it requires nearly constant access to
the server for its operation.  (E. g., to examine the prior
history, check the diff's, etc.)

Alternatively, one can run svnsync(1) to get a replica of a
Subversion repository, but it's a costly operation (or at least
it was the last time I've tried), primarily for the server the
repository is hosted on.  (Using git-svn(1) against a remote
server incurs, I believe, roughly the same amount of burden on
the latter.)

However, if it's agreed upon, I may perform the svnsync(1) +
git-svn(1) combination by myself, and clone the result to a
publicly-acessible repository (perhaps on Gitorious.)

TIA.

looking up a registered fcfs string?

sngh — 2012-08-27T12:24:22

Bit of a mess here, I have several public key files here or those
hashes, but I dont know the "registered" domain names within fcfs any
more
can anyone add a lookup feature on the fcfs registration website or is
there any other way to lookup a name record?

if its working dns-like there should be a way to lookup an fcfs entry
even with the gnunet tools and within gnunet itself if I have the
public key.
Thanks in advance.

about the FCFS registration and the pubkey - which pubkey to really use? -s? or really -P?

2012-07-16T17:07:43

Hello list,

I am rather a newbie here, and not exactly any kind of developer,
still I am trying to look into the gnunet and these new dns zones and
the fcfs subzone.

I have self-compiled 0.9.3 and tried to register some zone (do you
only type the subzone name, or a complete one on the fcfs regsite?),
but I think the only time it succeeded was, when I actually used not
the gnunet-rsa -P command but the gnunet-rsa -S command to get the
short/hashed pubkey of my installation.

Is that a bug in documentation at:
https://gnunet.org/gns-fcfs-authority-started

also on:
https://gnunet.org/fcfs/
please give examples next to the textbox fields, that would make it
easier for the user.

so is
What is your desired domain name?
myzonename.fcfs.gnunet.

or rather only
myzonename

and the public key, is it really supposed to be generated via
gnunet-rsa -P ~/.gnunet/gns/zonekey.zkey

rather than
gnunet-rsa -s ~/.gnunet/gns/zonekey.zkey?

The script/registrationwebsite constantly gave me errors until I
actually switched over and used the -s (256bit hashed private key
according to manual) parameter.

Where would my registered subzone actually show up on my local system?
gnunet-setup nor any of the gtk tools showed me anything else than
only a plain "fcfs" entry after that import .sh script, and not even a
nested fcfs.gnunet. entry or anything.

I used to do a bit of dns-admin in the past and ran some local
(internal) dns zones of my own on LAN/WAN networks, but I have yet to
understand were we are headed once we register our own subzones to
that fcfs.gnunet. zone.

Also, after I did a registration with my private key (-s one) I
couldnt register any further zones with that key any more, the
registration website refused to use this same private key for
additional entries. Is this on purpose? How do we practically register
multiple zones and have multiple private/public keys in use.

Thanks. Regards.

A few typos

Bertrand Marc — 2012-07-13T21:12:15

Dear GNUnet developpers,

You'll find attached a patch fixing a few typos (lintian was pocking me 
about these) in gnunet.

Happy hacking,
Bertrand
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers< at >gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Keyword queries shouldn't reveal the namespace

Kenneth Almquist — 2012-06-25T02:35:45

1.  The Issue

In GNUNET, keywords are passed through a one-way function before being
published or queried.  However, the namespace is published and included
in all queries.  There are several reasons why this is undesirable.

First, namespaces, like keywords, may be targets for censorship.  In
fact, the contents of a namespace are likely to represent a particular
viewpoint.  This should make them a particularly attractive target for
censorship by Western governements, which generally want to censor
particular types of materials in a way that doesn't restrict the
distribuation of other types of materials that are not targets for
censorship.  GNUNET uses a one-way function to hide the keywords in
queries.  It should hide the namespace as well, for the same reasons.

Second, the content of a GNUNET query can be determined by guessing.
The current design makes this type of attack unnecessarily easy by
revealing the namespace, meaning that the attacker only has to guess
the keyword, rather than being forced to guess a pair of values consisting
of a namespace and a keyword.

Third, specifying the namespace in a query (rather than making all queries
look alike to any attaker which fails to guess the query) might make
attacks based on traffic analysis easier.

Fourth, the current design treats queries of the global namespace
differently that queries of other namespaces.  This means that GNUNET
has to support two types of keyword searches, which makes the system
more complex at a conceptual level, and may make the code more complex
as well.  Consider, for example, that GNUNET currently guarantees that
if a response to a query in the global namespace contains a valid
signature, then the response was generated by someone who knew the
keyword.  However, if the query was for a namespace other than the
global namespace, then there is no such guarantee.  Having a single
keyword search mechanism that applied to all namespaces would eliminate
this sort of discrepancy, making the security properties of GNUNET
simpler and easier to understand and reason about.


2.  Our Proposal

In the current design of GNUNET, searches in the global namespace use
K-blocks.  Our proposal, in a nutshell, is to make a K-blocks use a
<namespace, keyword> pair, rather than just a keyword, as the search
key.  KS-blocks, currently use for searches of a keyword in namespaces
other than the global namespace, go away.

The remainder of this section explains the technical details of how this
works.

2.1.  DSA

Our design uses DSA to generate digital signatures.  To use DSA, it is
necessary to select three parameters:  p, q, and g.  A single set of
parameters should be chosen for use by all GNUNET participants.

Private keys in DSA are integers in the range 1 thought q - 1.  To simplify
the exposition, we will assume for now that DSA also allows 0 to be used
as a private key.  We will revisit this assumption in section 2.6.

If x is a private key, the corresponding public key is g^x mod p.

2.2.  Namespaces

As with the current GNUNET design, a public/private key pair define a
namespace.

One namespace is designated as the global namespace, and its private
key is made public so that anyone can publish to the global namspace.
Any namespace could be used as the global namespace, but for aesthetic
reasons I would chose 0 as the private key for the global namespace.

2.3.  Generating the Signature Key for K-blocks

Each K-block is signed by a key which is derived from the namespace and
the keyword.  Let x be the private key of the namespace.  Let h be a
value, in the range 0 through q-1, generated by hashing a combination of
the public key of the namespace and the keyword.  The private key used
to sign the K-block is x+h mod q.

This prevents a K-block from being forged by anyone who doesn't know
both the namespace private key and the keyword, because without knowing
these it is impossible to generate a valid signature.

We will discuss the details of signing in sections 2.6 thorough 2.8, but
first we consider query generation.

2.4.  Generating Queries

To perform a query, it is necessary to know the public key which
corresponds to the private key used to sign the K-blocks being
searched for.  The private key is x+h mod q, so the public key is:

        g^(x+h mod q) mod p

To compute the this without knowing the value of x (which is the
private key of the namespace), we proceed as follows.  DSA requires
the parameters be chosen such that

        g^q mod p = 1

so

        g^(x+h mod q) mod p = g^(x+h) mod p

Standard algebra tells us that

        g^(x+h) mod p = (g^x * g^h) mod p
                      = ((g^x mod p) * g^h) mod p

g^x mod p is the namespace public key, and h is a hash of the namespace
public key and the keyword.  Therefore, a query can be generated by
anyone who knows both the namespace public key and the keyword.

2.5.  Contents of a K-block

A K-block contains the following values, which are essentially the
same as in the existing design:

1)  The payload (typically a URI followed by metadata).  This is the
data returned by search that matches the K-block.  The payload is
encrypted using a symmetric encryption key generated from a hash of
the namespace public key and the search keyword.  This means that only
someone who knows the search criteria (namespace and keyword) can decode
the payload.

2)  The public key used to sign the payload.  Since this key is derived
from the namespace and the keyword, it (or a hash of it) can be used
as the search key.

3)  A digital signature of the encrypted payload using the public key
listed above.  A valid signature can only be generated by someone who
knows both the private key of the namespace being searched and the
keyword being searched for, so the signature can be checked to filter
out bogus K-blocks.

2.6.  Zero as a Private Key

As noted in section 2.1, the DSA specification does not permit a private
key of zero.  There are two ways we can deal with this.  One is to modify
the procedures described in sections 2.3 and 2.4 to avoid a private key
of zero.  If the sum x+h mod q turns out to be zero, rather than using zero
as the private key, we hash a combination of the namespace public key and
the keyword to produce a value in the range 1 through q-1, and use that
value as the private key.  In section 2.4, we don't compute the private
key, so rather than comparing the private key to 0, we compare the public
key to the public key which corresponds to a private key of zero.

Although the approach described in the preceding paragraph would work,
it appears unnecessary.  The requirement that the private key be
non-zero doesn't appear to be necessary for correctness, because a
look through the proof of correctness for DSA reveals no steps that
depend upon the assumption that the private key is nonzero.  Nor is
the requirement that the private key be non-zero necessary for security,
because the difference in security between DSA variants with or without
the requirement that the private key is nonzero can be proved to be
trivial.

We now present the proof referred to in the preceding sentence.  In
what follows, we will use the name DSA1 to refer to the standard DSA
algorithm, where the minimum value for the private key is 1, and DSA0
to refer to a variant where then minimum value of the private key is
zero rather than one.

Suppose that we have an algorithm that will break DSA0 in an expected
time T, assuming that the private key is randomly selected with a uniform
distribution.  This algorithm will also break DSA1.  To determine maximum
run time for this algorithm when used to break DSA1, we assume that the
run time of the algorithm is zero when used to break an instance of DSA0
where the private key happens to be zero.  It then follows that the
expected run time if the private key is non-zero will be T * (q/(q-1)).
Since the actual run time for a zero key must be greater than zero, the
actual time to break DSA1 must be less than T * (q/(q-1)).  For a
realistic value of q, the difference between 1 and (q/(q-1)) is trivial.

Conversely, suppose that we have an algorithm that will break DSA1 in
an expected time T.  We can break DSA0 by first checking whether the
public key is 1 (which corresponds to a private key of 0), and then
running the algorithm to break DSA1 if the check fails.  The expected
run time will be C + T * ((q-1)/q), where C is the time required to
compare the public key with 1.  Assuming that DSA has any meaningful
resistance to attack, the value of C will be trivial compared to the
value of T.

In short, the security of DSA0 and DSA1 are essentially identical, so
there is no reason not to use DSA0.

2.7.  Generating a value of k for signing K-blocks

Constructing a digital signature using DSA requires chosing a value of k
in the range 1 through q-1.  We want to chose k using a deterministic
fashion so that if the same K-block is published more than once, the
signature won't change.  In addtion, we want to be sure that we don't
chose k in a way that will help an attacker.  To generate k, we compute
a cryptographic hash of the private key combined with the data being
signed.  This ensures that:

1)  At attacker who does not know the private key cannot determine the
    value of k.

2)  The probability of using the same value of k for two different
    signatures, if either the signing key or the data being signed is
    different, is the same as if k were chosen using a true random
    number generator.

3)  Repeatedly signing a given value with a given key will always use
    the same value of k, thereby producing the same signature.

The data being signed (the payload) is encrypted.  We could use the
unencrypted payload rather than the encrypted payload as input to
the hash function.  It doesn't matter which we use if the hash function
is secure.  If the hash function is not secure, using the unencrypted
payload won't really help because anyone who received the K-block as
a query result will be able to decrypt the payload.  So we specify that
the encrypted payload is to be used as input to the hash function, but
that choice is arbitrary.

2.8.  Avoiding Collisions

In section 2.3, we specify that h is based on a hash of the namespace
public key and the keyword.  In this section, we explain why it is
necessary to include the namespace public key in the input to the hash.

Suppose that the only input to the hash was the keyword.  Then if we
had two keywords K1 and K2, we would have corresponding hash values
h1 and h2 which would be independent of the namespace involved in
the query.

Suppose further that we have a namespace N1 for which we know the
private key x1.  The private key associated with a search for K1 in
namespace N1 is then (x1 + h1) mod q.  We can then define a new namespace
N2 with a private key x2 = (x1 + h1 - h2) mod q.  The private key associated
with a search for K2 in namespace N2 will then be
    (x2 + h2) mod q = (x1 + h1 - h2 + h2) mod q = (x1 + h1) mod q
In other words, we have produced a collision where the searches <N1, K1>
and <N2, K2> both produce the same search key.  Including the namespace
public key as an input to the hash prevents this attack.


3.  Conclusion

The design in section 2 shows that it is technically feasible to hide
the namespace as well as the keyword in GNUNET queries.  That design
used DSA, because it has a long track record, but it should be possible
to substitute a different ElGamel variant if desired.

One of the stated goals of GNUNET is to provide deniability.  Hiding
the namespace in queries would improve the ability of GNUNET to meet
that goal.

more reports

Mike Dupont — 2012-06-07T14:49:08

Hi there,
using svn head,

I had a segfault uploading, trying to reproduce this.

Another bug is that the indexed file dialog is not displaying properly too
small, on the come
gnunet-fs-gtk:3884): Gtk-WARNING **: Unknown property:
GtkDialog.has-separator

you want a bug report? bugzilla?

mike