Jump to content

Some Suggestion And Ideas


Recommended Posts

I love this project and I'd like to contribute with some ideas.


  • Could be possible to implement a two-step verification with Google Authenticator or something like Keepass Password Manager (password+if you want a key file) to access to the application? I think it would be quite useless to have the best software when anyone could break it just accessing to the application. 
    • Linked to this point: No password recovery. I'd like a zero-knowledge service like SpiderOak or Mega. Do you lose the password? Say hello, create another password, anothers private and public key and restart the game. Period.
    • I'd like to have the possibility to revoke the keys if I think they have been compromised.
  • I everyday use on my smartphone and tablet and PC apps like Chatsecure, TextSecure and GPG to keep my conversations private. I'd like to have the possibility like in GPG to choose the encryption key, the SHA algorithm (SHA-512 by default?), encryption algorithm like RSA or so on, and finally the keysize (maybe just you options, 2048 and 4096).


    gpg --version
    Home: ~/.gnupg
    Supported algorithms:
    Pubkey: RSA, ELG, DSA
    Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
    Compression: Uncompressed, ZIP, ZLIB, BZIP2


  • The possibility to choose and set the key in my opinion has two pivotal consequences: 
  1. Every users choose it at his own risk
  2. If a user want to set an easy-to-remind key he is free to do so, while I who I use a password manager, can set a 150 ASCII characters key with additional entropy without any problem. 
  • Will video calls be available in future and encrypted videocalls?
  • What about forward secrecy?
    • There will be only one fingerprint check or a periodic verification of it?
  • Will self-deleting messages be introduced? Yeah, I know that this gives a false-sense of security because there is always the possibility to make screenshots, but...
  • Personal informations and metadata. On this point you have done a great job, but why not introduce a sort of alphanumeric short string (5-10 characters) like Blackberry Messages so you can share this preserving your privacy about email and phone number?
  • There will be the possibility like in chatsecure and Textsecure to send or share encrypted attachments?
  • One pivotal and of uttermost importance for me feature I miss most for OTR messaging: the multi-session-multi-device chats: I'd like, as in Google Hangout, to start an encrypted conversation on the smartphone, continue it on the PC and end it on the tablet.
  • Strictly speaking about privacy: will the conversations be saved anywhere? I can renounce to the previous point to save my privacy only if in exchange I have the conversation locally saved in a strong encrypted folder.
    • Related to this point: I'd like to have the possibility to deny the other user's choice to save the conversations and its history. A clear easy message: the other user wants to save the conversation: do you agree? Yes, No.


These are my two cents, I'd like they will be useful not only to the developers but to the whole community and I'd like to discuss them with you.

Link to comment
Share on other sites

Don't you think that having to rely on a 3rd party "two step" authentication process kinda defeats the point it being a secure, distributed, P2P solution where you're in control!? :P
Anyway, on a more general note on security/keys/encryption/"two factor" authentication, I'd suggest having a look at these existing threads: 1 | 2 | 3 | 4 | 5 | 6 | 7

Whilst these relate to Sync as opposed to Bleep, the same general principles apply in terms of P2P security of Sync/Bleep and have been discussed/debated extensively!

Link to comment
Share on other sites

Don't you think that having to rely on a 3rd party "two step" authentication process kinda defeats the point it being a secure, distributed, P2P solution where you're in control!? :P



Thank you Marko! I'll carefully read what you have linked but if I reply to the quotation, as you can read in this page written pretty well there are multiple and different ways to implement an effective and efficient multi-step authentication and 


Two-factor authentication requires the use of two of the three independent authentication factors. Each of the independent factors are identified in the standards and regulations for access to U.S. Federal Government systems. These factors are:

  • Something only the user knows (e.g., password, PIN, pattern);
  • Something only the user has (e.g., ATM card, smart card, mobile phone); and
  • Something only the user is (e.g., biometric characteristic, such as a fingerprint).


So, we can say that having a trusted and private (and really strong and enough complex and long) password in addition to a broadly diffused app for a two-step authentication could pretty well balance with features of privacy, security and user-friendliness   with the use of a third-party application.


Don't you want use google authenticator? Perfect. No problem. But please allow the user to set a keyfile like in Keepass, decide where to store and use it if he wants. 


Don't you agree on this point?


As user, I really appreciate every efforts to make conversations private, but always as user (employer? lawyer? journalist? private citizen? lover? father working in a not-so-civil-country?) , because this application is in pre-alpha stage yet, I think that every person ought to give is opinion and suggestions to improve it.


Don't you agree on this point?


As tester, in your opinion and experience (and because you have much more messages than me :D ) , and because I'm interested in learning new things, have I said and proposed stupid and unreliable things, or I have described real and everyday problems?


And if you allow me, I'd like to propose a possible new (interesting?) feature: a sort of "panic button" which securely erase the content of the encrypted folder in which are stored messages' histories and conversations.


Thanks for your attention and reply.

Link to comment
Share on other sites

The point of Bleep (and indeed Sync) is that they are P2P and decentralized - there is no central authentication authority/server.

The moment you start requiring a password/pin, etc you then need some form of central authority/repository/server in which to authenticate against.


As I say, please do have a read of the topics I've linked to above, as you're not alone in your doubts over security. For example, when Sync first launched a number of users argued it wasn't secure enough because they weren't used to using a solution that didn't require them to "login" in some way or another first!
As you'll see from those discussions, and also from this documentation on the technology/security behind Sync (equivalent Bleep documentation isn't yet available, but similar core principles apply), actually the way both Sync and Bleep work are extremely secure! :)

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...