CryptoList - Looking for beta testers

Oliver Verlinden oliver at
Mon Sep 23 08:03:54 CEST 2013

> Very cool to see that you've done this work and that you want to see
> something like this happen.  It raises a lot of questions for me,
> though: 

Ok, let me answer them. ;)

> how does your system know whose keys are whose?  

The key is picked by one or more given email addresses. The recipient email 
address drives the key selection.

> what if a key expires?  

Expired keys are not better then non available keys. Encryption will fail and 
the list admin is notified.

> how does it handle new subscribers?  

... need to be added to the list manually. I don't want to add encryption keys 
automatically. The list admin should check the level of trust, so this is used 
to be a manual task. I asume that the list of subscribers is mainly fixed and 
changes are a rare event.

> who gets access to the lists?  

See above. In productive environments the list admin is hosting my software 
and of course may decide who to give access to the list. 
In this list I am searching for beta testers so everyone who is interested 
will get access.

> are they archived?  

No archive functionality at the moment.

> what about messages that can't be delivered
> right away?

At the moment delivery failures are not handled. So if the outbound mail 
server does not accept the message, it will be skipped.
In the future some errors should have a retry count and be processed again 
after some time.

> How do i as a user know what keys to encrypt to?  

You only encrypt with the list's public key. 

> how do i as an admin make sure my user's confidential data doesn't leak to
> outside parties?

As the list subscribers are added manually by you (as the admin), you should 
only give trustful people access to the list.
The list itself does not leak any confidental information. Of course if you 
have a untrusted member in the list he will receive the confidental shared 
information (in a encrypted way, but he is able to unencrypt and read them)

> Dealing with store-and-forward message delivery in a dynamic network is 
challenging in its own right

What do you mean with store-and-forward handling. Can you explain?

> Regards,
> 	--dkg

Best regards
Oliver Verlinden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20130923/73d56b2a/attachment.sig>

More information about the Gnupg-users mailing list