Seems to me neither of you read the reference I gave:
I (Adam) wrote:
It is tricky to get forward secrecy for store-and-forard messaging [2],
but perhaps you could incorporate rekeying into your protocol in some
convenient way.
...
[2] http://cypherspace.org/adam/nifs/
Not impossible just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/13 02:49, Jonathan Warren wrote:
Suppose when Alice firsts sends a message to Bob she also includes
a short term public key. Bob takes the short term public key and
encrypts symmetric_key_1 (SK1) and also encrypts a message with
SK1 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 20/02/13 02:49, Jonathan Warren wrote:
Suppose when Alice firsts sends a message to Bob she also includes
a short term public key. Bob takes the short term public key and
encrypts symmetric_key_1 (SK1) and also encrypts a message with
SK1 and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jonathan,
This looks like it could be a useful system, but I'm not sure I fully
understand it.
Each node is assumed to have a slowly changing set of addresses, is
that right? A node migrates between streams by choosing whether to
create new
IMO you might want to do something about forward secrecy (aka backward
security) and forward anonymity, or you arguably end up with the same issue as
reply blocks: a subpoena plus suspicion can force decryption (you won’t have
the decrypt the reply-block via repeated subpoenas down the chain,
On 2013-02-20 6:21 AM, Jonathan Warren wrote:
It is tricky indeed. The handshaking necessary to set up the session key could
piggyback on the first couple messages that users send to one another although
those first several messages would not be forward-secret. I suppose that the
session key
If store and forward, cannot be forward secrecy.
Suppose that human readable messages, messages that might contain important
secrets, are only exchanged when the sender and the final recipient are both
online at the same time, then forward secrecy no problem. Both parties set
up a shared
Hello everyone, I would like to introduce you to a communications protocol I
have been working on called Bitmessage. I have also written an open source
client released under the MIT/X11 license. It borrows ideas from Bitcoin and
Hashcash and aims to form a secure and decentralized communications
On Sat, Feb 16, 2013 at 01:49:18PM -0500, Jonathan Warren wrote:
Hello everyone, I would like to introduce you to a communications protocol I
have been working on called Bitmessage. I have also written an open source
client released under the MIT/X11 license. It borrows ideas from Bitcoin and
With no criticism to the idea and motivation there are similarities with
having a reply-to of a newsgroup such as alt.anonymous.messages, which is
used as a more secure alternative to reply blocks. To pickup those messages
anonymously you'd ideally need to be able to unobservably download
On 2013-02-17 4:49 AM, Jonathan Warren wrote:
A primary goal has been to make a clean and simple interface so that
the key management, authentication, and encryption is simple even for
people who do not understand public-key cryptography.
This is precisely how I2P eepsites work. The true addresses are [52
characters of b32 encoded checksum of public key].b32.i2p while the
hosts.txt file is a list of these with their readable [sitename].i2p
domains. You can modify your own lists as you wish.
I2P Messenger and Bote mail could be
12 matches
Mail list logo
