Topic: [ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin - page 13. (Read 89873 times)
July 12, 2013, 08:46:33 PM
I don't see how it's better and there's no client.
July 12, 2013, 05:22:01 PM
The other day I read about OTR, Off-the-Record Messaging, which seems superior to Bitmessage in some ways, but can probably be usefully combined with it. There's a comparison chart on the Bitmessage wiki, but it leaves out the strengths of OTR (perfect forward secrecy and deniability), unjustly making it look inferior.
Off-the-Record Communication, or, Why Not To Use PGP
Wikipedia describes OTR as follows:
Off-the-Record Communication, or, Why Not To Use PGP
Wikipedia describes OTR as follows:
Quote
Off-the-Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric-key algorithm, the Diffie–Hellman key exchange, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption.
The primary motivation behind the protocol was providing deniability for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing. This is in contrast with other cryptography tools that produce output which can be later used as a verifiable record of the communication event and the identities of the participants. In most cases, people using such cryptography software are not aware of this and might be better served by OTR tools instead. The initial introductory paper was named "Off-the-Record Communication, or, Why Not To Use PGP".
The primary motivation behind the protocol was providing deniability for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing. This is in contrast with other cryptography tools that produce output which can be later used as a verifiable record of the communication event and the identities of the participants. In most cases, people using such cryptography software are not aware of this and might be better served by OTR tools instead. The initial introductory paper was named "Off-the-Record Communication, or, Why Not To Use PGP".
July 12, 2013, 05:13:54 PM
If Bitmessage's encryption is broke, how will an extra PGP encryption help? Don't they both use the same encryption algorithm?
Not necessarily and unlikely. Most PGP use RSA and bitmessage is using ECC.
July 12, 2013, 03:03:17 PM
If Bitmessage's encryption is broke, how will an extra PGP encryption help? Don't they both use the same encryption algorithm?
July 12, 2013, 07:11:43 AM
That could make a killing. Who wants to join me in making the next Gmail?
July 12, 2013, 01:54:55 AM
No implementation. Do it yourself. Keep it segregated. Gpg4win is great.
July 12, 2013, 01:33:41 AM
I mean bm is almost pgp, million times better than email, but why not also add pgp. It's just an extra second vs in jail for years.
+1 for pgp, shouldn't be too hard to implement, right?
July 11, 2013, 04:43:45 PM
No. I'm skeptical about hemlis.
July 11, 2013, 04:38:53 PM
July 06, 2013, 07:28:25 PM
Yup and a lifetime in jail or Guantanamo would suck
July 06, 2013, 07:01:24 PM
I mean bm is almost pgp, million times better than email, but why not also add pgp. It's just an extra second vs in jail for years.
What the hell are you involved in?
Edit: actually i don't want to know.
July 05, 2013, 07:03:39 PM
I mean bm is almost pgp, million times better than email, but why not also add pgp. It's just an extra second vs in jail for years.
What the hell are you involved in?
Edit: actually i don't want to know.
July 05, 2013, 02:49:50 PM
I mean bm is almost pgp, million times better than email, but why not also add pgp. It's just an extra second vs in jail for years.
July 05, 2013, 02:44:50 PM
I would still use pgp.. for certain messages. Bm hasn't been fully audited yet, a vulernability could exist.
Plus your keys could be stolen like a wallet.
Its motivating that Im not the only paranoid person here Plus your keys could be stolen like a wallet.
I believe that paranoia is an evolutionary benefit in the society we got today. July 05, 2013, 02:36:36 PM
I would still use pgp.. for certain messages. Bm hasn't been fully audited yet, a vulernability could exist.
Plus your keys could be stolen like a wallet.
Plus your keys could be stolen like a wallet.
July 05, 2013, 02:32:44 PM
Is it overkill to use PGP for the messages sent with BitMessage? (encryption^2)
July 04, 2013, 01:33:41 AM
Just to let you know (I already posted in the Bitmessage forum though, so a lot of people reading this may already have seen it anyway), I just started work on integrating namecoin identities with the bitmessage client, see https://dot-bit.org/forum/viewtopic.php?f=2&t=1004.
June 25, 2013, 04:39:41 PM
Why not make it so one can use a Bitcoin address / keypair for messaging?
Bitcoin and Bitmessage keys will be interchangeable. Today I coded the key generation sections; Bitmessage will even save keys in Wallet Import Format.
However Bitmessage will use two keys- one for encryption and one for signing. Thus Bitcoin addresses (which are only a hash of a signing key) wouldn't be sufficient for Bitmessage. It seems to me that Bitmessage addresses could be turned into Bitcoin addresses but not the other way around.
This is gonna be cool.
Now you could store those Bitmessage/Bitcoin keys in a namecoin 'alias' namespace http://dot-bit.org/Namespace:Aliases and have the Bitmessenger client just send to a human-readable name from the namecoin blockchain ... voila ... end-to-end secure, autonomous look-up, authenticated, human-readable messaging system.
Namecoin development is on overdrive right now (there are working implementations of TLS / Namecoin-QT / OpenNameId / independent local DNS proxy and lots more in NMControl / easy to install .bit plugins and server based local DNS proxy)....
Atheros and everyone else, what is your stand on this, is there still interest, how could this look like? From a Namecoin point of view a bitmessage address could simply be included in the id namespace (see http://dot-bit.org/Namespace:Identity at the very bottom) but how would the integration work on the bitmessage side?
Here there is a thread about it on the Namecoin forum: http://dot-bit.org/forum/viewtopic.php?f=2&t=1004
There might be
About the Namecoin blockchain size issue: Hopefully there will be client with light checking like Multibit some time.
June 22, 2013, 10:43:17 PM
I made some test and it looks like the creator of the pseudo-mailing-list must be online in order messages send to this address to be received by subscribers.
Why this is needed? Why messages cannot be received if the creator of the pseudo-mailing-list is offline?
Because a pseudo-mailing-list, unlike a chan, works almost exactly like a normal mailing-list: you send a message to the server, and then the server re-broadcasts your message to everybody.Why this is needed? Why messages cannot be received if the creator of the pseudo-mailing-list is offline?
Thank you. Now I understand. I just updated my blog post about this.
June 22, 2013, 10:23:04 PM
I made some test and it looks like the creator of the pseudo-mailing-list must be online in order messages send to this address to be received by subscribers.
Why this is needed? Why messages cannot be received if the creator of the pseudo-mailing-list is offline?
Because a pseudo-mailing-list, unlike a chan, works almost exactly like a normal mailing-list: you send a message to the server, and then the server re-broadcasts your message to everybody. Why this is needed? Why messages cannot be received if the creator of the pseudo-mailing-list is offline?
Jump to: