[Richard Buckley]

The best thing BBM could do to up its security is implement OTP support for every message. That way, no message can be decrypted from the outside. But that would require BlackBerry to invest heavily in more powerful servers than they currently have.

Posted via CB10 using my amazing  Passport (OG Red)

What do you mean by OTP?

LeapSTR100-2/10.3.3.2163

[Vistaus]

What do you mean by OTP?

LeapSTR100-2/10.3.3.2163

One Time Pads.

Posted via CB10 using my amazing  Passport (OG Red) <3

[app_Developer]

One Time Pads.

How would you share the key between the two users who are communicating?

This is the reason OTP is not practical, and the reason why other ciphers exist.

[hobgoblin1961]

The best thing BBM could do to up its security is implement OTP support for every message. That way, no message can be decrypted from the outside. But that would require BlackBerry to invest heavily in more powerful servers than they currently have.

Posted via CB10 using my amazing  Passport (OG Red)

BBM Protected offer this "every time password handshake" to confirm vor every message already, but it's not very practical so usually allow settings vor automatic handshake for convenience.
Called "BBM Protected Autopassphrase" and can be set by the admin who entitle for each user!

Posted via -Passport -Classic / OS-10.3.++ is all you need

[hobgoblin1961]

List of options in service configuration in BBM Protected as Opt-in:
BBM Protected cloud Directory service: on/off
BBM Protected Wipe Date: on/off
BBM Protected Disable Channels: on/off
BBM Protected Enable Manual Passphrase: on/off
BBM Protected disable Retracted and Edit message: on/off
BBM Protected disable Timed Message n/off
BBM Protected Message expiry: set amount
BBM Protected disable Voice Calling: on/off
BBM Protected enable Team Messaging for Healthcare: on/off
BBM Protected Disable Copy: on/off
BBM Protected Enable Team Messages: on/off
BBM Protected Disable Video Calling: on/off
BBM Protected Disable BBM shop: on/off

As you can see there are quite a few security tweaks that can be set for BBM
And yep no BES needed to do so...

Posted via -Passport -Classic / OS-10.3.++ is all you need

[hobgoblin1961]

And that's how it looks like if the 1st initial secured ETE-keyexchange handshake was established from the other person with autopassphrase enabled.
This will remain until someone switched devices and locks in to BBM again or starting a new chat with some one else.
So in short there is a individual ETE key with every single contact in the contact list as long as the opened chat is active, if opened a new chat or adding a new person so a new ETE key will be agreed like showing in the picture.
A manual passphrase is just time wasting and confusing less advanced user because it scare theme


Posted via -Classic -Passport / OS-10.3.++ is all you need

[Vistaus]

How would you share the key between the two users who are communicating?

This is the reason OTP is not practical, and the reason why other ciphers exist.

You can automate that process, there are tools for that. There are a few chat apps who've implemented it so it's not impossible, it's just impractical as long as BlackBerry doesn't buy more servers to handle the extra processing power.

Posted via CB10 using my amazing  Passport (OG Red)

[app_Developer]

You can automate that process, there are tools for that. There are a few chat apps who've implemented it so it's not impossible, it's just impractical as long as BlackBerry doesn't buy more servers to handle the extra processing power.

No, you're not understanding the issue. Let's say I'm sending you a message that is 80 bytes long.

So I create an 80 byte pad and XOR it with the message . Fine. How can I securely get the pad to you so you can decode my message?

I would need a secure way to send you the 80 byte pad, right? Well, if I have a secure way to send you the pad for every single message (of equal length to the message), then I could just use that secure method to send you the message itself.

This is why OTP doesn't work as a practical mechanism for securing messages. Yes, it gives you theoretically perfect security, but it can't be used to build a messaging service because it "solves" one problem by creating an equally sized problem of its own. You have to securely send the pad itself so the other user can decrypt your message.

Practical ciphers involve sharing a key that isn't the length of the entire session.

[Vistaus]

No, you're not understanding the issue. Let's say I'm sending you a message that is 80 bytes long.

So I create an 80 byte pad and XOR it with the message . Fine. How can I securely get the pad to you so you can decode my message?

I would need a secure way to send you the 80 byte pad, right? Well, if I have a secure way to send you the pad for every single message (of equal length to the message), then I could just use that secure method to send you the message itself.

This is why OTP doesn't work as a practical mechanism for securing messages. Yes, it gives you theoretically perfect security, but it can't be used to build a messaging service because it "solves" one problem by creating an equally sized problem of its own.

Practical ciphers involve sharing a key that isn't the length of the entire session.

I know how OTP works. But again: there are examples of chat apps experimenting with OTP and it works fine, it just requires a lot of server power. So it is possible. Take a look at this app, for example: https://github.com/cvrett01/OTPChat or maybe even this one for a semi-manual approach unlike OTPChat's near-automatic approach: https://techcrunch.com/2015/03/24/on...ds-ride-again/ and Mitsubishi is also onto something: http://www.mitsubishielectric.com/co...s/quantum.html

Posted via CB10 using my amazing  Passport (OG Red)

[app_Developer]

I know how OTP works. But again: there are examples of chat apps experimenting with OTP and it works fine, it just requires a lot of server power. So it is possible. Take a look at this app, for example: https://joshua-m-david.github.io/jerichoencryption/

All he's done is write his own generator, right? How is that different from every other every other cipher that uses a key to drive a generator?

This is how most ciphers work.

As for Zendo, would you really suggest that BBM require users should always meet in person before they communicate? Seems impractical, don't you think? And how would you do multi person chats?

[Vistaus]

All he's done is write his own generator, right? How is that different from every other every other cipher that uses a key to drive a generator?

This is how most ciphers work.

See my updated post for two other examples.

Posted via CB10 using my amazing  Passport (OG Red)

[app_Developer]

You clearly haven't read the presentation. Also, see my updated post for another example.

Posted via CB10 using my amazing  Passport (OG Red) <3

If you mean Zendo, every pair of people have to meet in person to generate the shared pad. I don't think that's very practical for a service like BBM, is it?

[Vistaus]

If you mean Zendo, every pair of people have to meet in person to generate the shared pad. I don't think that's very practical for a service like BBM, is it?

I didn't say BBM should ditch the current implementation, I just said that they could implement OTP support as an option, just like BBM Protected has extra security options. For friends and colleagues, the Zendo approach works fine, same goes for BBM should they implement the option.
Also, look at the presentation of OTPChat I linked to, that's also a good approach.

Posted via CB10 using my amazing  Passport (OG Red)

[app_Developer]

I didn't say BBM should ditch the current implementation, I just said that they could implement OTP support as an option, just like BBM Protected has extra security options. For friends and colleagues, the Zendo approach works fine, same goes for BBM should they implement the option.
Also, look at the presentation of OTPChat I linked to, that's also a good approach.
)

OTPchat works basically the same way as Zendo. Two users get together and generate a pad long enough to handle all the messages they may need.

So the good news is if BBM wanted to implement this, they wouldn't need any significant server-side changes at all. All the work, including the in-person pairing, would be client-side. It has to be, if you think about it.

[Vistaus]

True. Btw, I also stumbled upon this, looks very interesting as well but not practical for BBM, maybe for BES if automated properly: https://github.com/maqp/tfc

But as you can see, OTP in a messaging app *is* practical, even if only among friends and/or presidents. So I vote for BBM implementing it as an option using the Zendo/OTPChat approach.

Posted via CB10 using my amazing  Passport (OG Red)

[app_Developer]

True. Btw, I also stumbled upon this, looks very interesting as well but not practical for BBM, maybe for BES if automated properly: https://github.com/maqp/tfc

But as you can see, OTP in a messaging app *is* practical, even if only among friends and/or presidents. So I vote for BBM implementing it as an option using the Zendo/OTPChat approach.

We may have different definitions of what is "practical".

I would agree, though, that this would be an interesting option for BBM to offer. It would not be difficult or expensive to implement at all. You should suggest it to them!

[Richard Buckley]

The OTP projects and articles that have been quoted here recently are certainly interesting if taken at face value, but when looking at crptography implementations it is always use full to remember Ron Bowes 2013 Shmoocon talk: https://forums.crackberry.com/e?link...token=6XlWz5wi which is entertaining as well as informative.

So here are some properties of OTP that are advantages or disadvantages and some caveats.

1. OTP is mathematically unbreakable. This is true only if your key pads are generated through a true random process. So the first thing to check in any of these OTP projects is that they are using a true random soruce to generate the key pads. It is very difficult to generate true random numbers, and because it is difficult it can take a lot of time to generate sufficient key material. You need a cryptographically strong random number generator. The corollary to being mathematically unbreakable is that if the key is ever disclosed your opponent has mathematical proof you exchanged the message that was encrypted with that key. This leades to the next point.

2. OTP is only as secure as the method of key exchange. Even if you have a cryptographically sound random number generator and you exchange your key pads using Bluetooth, the resulting communication system is only as secure as the Bluetooth exchange. If you store your key pads on a trivially exploitable storage system the resulting communications are only as secure as that storage system. These two weaknesses have been the main historical weaknesses of OTP systems. You can encrypt the key pad material at each end point, but then the security of the whole system is only as secure as that encryption system. So you may as well just use that encryption system to secure the communications.

3. I could not find where the idea that OTP is a burden to the server comes from. Properly implemented OTP is no greater burden on the communications channel than sending the same plain text would be. In fact OTP was used for years with hand written letters or hand sent telegraphy, so if you really want to use OTP with your favourite chat system you can.

4. If key material is ever re-used the strength of the OTP system is greatly reduced and is no longer mathematically unbreakable. This means that for practical purposes OTP can only be used for relatively small amounts of information.

5. Most importantly, OTP was an important means of cryptography until the spread of Feistel network cryptography and public key cryptography. Governemntest, buisnesses, intelligence organizations all had huge investements in generating and distributing OTP key material. The horse and buggy was an important means of transportation until the spread of the automobile. Horse husbandry can be an interesting hobby. The horse and buggy still has niche usage which can be both practical and profitable. But the horse is not in general use ouside those niche areas. OTP is in the same mode. It can be interesting to play with. The Zendo article brings up some interesting use case, but there are alread more secure, easier to use and more widely available chat programs that would satisfy those use cases that aren't very popular.

I have implemented several secure communications protocols on top of BlackBerry Pin-to-Pin messaging that are more secure than a OTP implementation could be because of considerations raised above. I would never invest any time implementing a OTP system over BBM. But since there are already open source projects, and it is possible to use BBM to send data between applications on BB10 devices any competent programmer could pick one and implemnet something.