View Full Version : Unbreakable cipher app
I'm thinking of writing an app that will make it possible to send small text messages that is not possible to decrypt. Is this legal? I live in Sweden and plan to publish the app on Openrepos which I think is located in Russia.
Edit: I meant decrypt without the key, of course. :)
I'd say it is legal in the free world.
BTW, what are you going to use as cryptoengine, and how can users be sure it really does as you advertise?
(not that I'm suspicious or anything, but always when there is a word "crypto" associated with anything, I tend to question motives...)
Also, keep in mind that "unbreakable" and "not possible to decrypt" are snake oil terms. More responsible approach requires stating clearly what is covered by your security model, and what isn't (see many great documents on TrueCrypt pages). That not even mentioning side-channel attacks.
Personally, I don't see much sense in such program, as encrypting things via any trusted cipher (with or without frontends/bundles, like TrueCrypt) and sending them as attachments *or* encrypted plain text, achieves just that (as long as receiver know password and have keyfiles, obviously).
You might aim for making it easier to use (i.e. user write a message, click "send", and software does all encrypting/sending, leaving tedious manual work apart), but that would be better achieved via frontend using actually existing tools - like, existing and already installed cipher packages and mail client, just acting as a middle-man - instead of reinventing the wheel all over again.
Nevertheless, good luck with your idea :)
/Estel
I would also add that doing crypto "right" is deceiviously hard, and it's one of those fields where it may be beneficial to do it open-source because:
1) you win trust of your users (as they know what engine you are using)
2) you can get an expert opinion from crypto guys that you implemented things right
Many recent mishaps in security happened because s/w developers improvised themselves as crypto guys, or viceversa.
Frankly, I would *never* deliberately use a closed source cryptographic application for anything sensitive (or, anything at all). No much reason to trust it more than some simple character replacement or any other "security through obscurity" method. Both are only usable if plain-text eavesdroppers are all that you expect.
/Estel
Thanks for the answers guys. I'm going to use Vigenere cipher with random generated keys that are as long as the encoded message and this is to my knowledge unbreakable. You can send messages with sms and Twitter and not NSA or your wife would be able to crack it. The problem with this cipher is that you have to keep your keys secret though and deliver them to your friend in a safe way, basically hand to hand. RSA type cipher is good but it's not theoretically unbreakable like Vigenere is.
But Vigenere cipher being unbreakable could mean that it's not legal to do ... in some countrys. Sweden is basically a US state when it comes to legal matters and I don't want a swat team kicking in my door giving me a single trip ticket to Gitmo. :) And I'm no criminal or anything but this is something I've been thinking about doing for almost twenty years when I first heard of the Vigenere cipher. So basically I'm doing it just because I want to but if it means trouble, like ie FSB puts Custodian in a black hole and destroys Openrepos servers I better not. :)
I'd say it is legal in the free world.
BTW, what are you going to use as cryptoengine, and how can users be sure it really does as you advertise?
(not that I'm suspicious or anything, but always when there is a word "crypto" associated with anything, I tend to question motives...)
I'm going to use Vigenere cipher with single use randomly generated keys that are as long as the message and this is afaik completely unbreakable, even in theory. It will of course be opensource otherwise I wouldn't dare to call it unbreakable. :)
IIRC, hasn't it already been cryptanalyzed and broken?
Personally, what I'd define as secure enough would be messages encrypted end-to-end with each message rekeyed via Diffie-Hellman key exchange.
That'd be really coo- oh wait, it exists (https://github.com/WhisperSystems/TextSecure/), and is vetted by some serious names in the security industry.
Cyanogenmod already integrated secure messaging into the ROM, it'd be nice if Maemo/MeeGo users could join in the fun.
Well, you are basically proposing using a one-time pad (http://en.wikipedia.org/wiki/One-time_pad) (if each message has unique key as long as the message). If you make sure the key is truly random & is only used once, it is provably unbreakable, provided you don't make a mistake in the implementation. :)
Still, while one-time pads are proof even against quantum computers, this solution seems like quite a big overkill to me. I think something based on widely used open source encryption libraries would be better fit, as it helps to solve the real issues that often lead to compromising of the encrypted information:
implementation errors - these libraries are opensource and widely used and by the many-eyes concept their source should be well audited for implementation errors by now
key exchange and integrity - if you can't make sure only the two parties in the conversation and none else is in possession of the shared secret, any encryption is useless; securely sharing just the keys for a good symmetric of asymmetric cipher should much easier than sharing full message length entropy
Yeah as MartinK said, Vigenere cipher used right is unbreakable (quoting Wikipedia):
If using a key which is truly random, is at least as long as the encrypted message and is used only once, the Vigenère cipher is theoretically unbreakable.
So what my app was going to do was only to encrypt the message and then you c&p to your messaging service of choice, that's it. But the Vigenere cipher used right being unbreakable could mean problems. But the TextSecure app Hurrian was talking about is probably good enough for most people.
Frankly, I would *never* deliberately use a closed source cryptographic application for anything sensitive (or, anything at all).
s/closed source/proprietary algorithm
Having worked for a crypto company myself (although not involved in the actual crypto stuff, so no tricky questions please, I am not an expert), I would have no problem using a commercial, closed-source application - as long as the actual algorithm is published. It is the guys that invent their own algorithms that I have no trust for. Security through obscurity is the least reliable kind.
Thanks for the answers guys. I'm going to use Vigenere cipher with random generated keys that are as long as the encoded message and this is to my knowledge unbreakable. You can send messages with sms and Twitter and not NSA or your wife would be able to crack it. The problem with this cipher is that you have to keep your keys secret though and deliver them to your friend in a safe way, basically hand to hand. RSA type cipher is good but it's not theoretically unbreakable like Vigenere is.
But Vigenere cipher being unbreakable could mean that it's not legal to do ... in some countrys. Sweden is basically a US state when it comes to legal matters and I don't want a swat team kicking in my door giving me a single trip ticket to Gitmo. :) And I'm no criminal or anything but this is something I've been thinking about doing for almost twenty years when I first heard of the Vigenere cipher. So basically I'm doing it just because I want to but if it means trouble, like ie FSB puts Custodian in a black hole and destroys Openrepos servers I better not. :)
You know, most things are decyphered not by breaking the crypting algo, but by breaking the PRNG
You know, most things are decyphered not by breaking the crypting algo, but by breaking the PRNG
Yeah I've noticed. In the Snowden leaks there was evidence of a NSA backdoor in one implementation:
http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_gener ator#NSA_backdoor_in_the_Dual_EC_DRBG_PRNG
But with some form of human interaction the keys can be made safer. I guess to type all the keys manually would be the safest way though. :)
Custodian
2013-12-30, 16:27
Openrepos which I think is located in Russia.
Primary openrepos servers are located at Germany, so dont worry about me or fsb ;)
btw, have you seen tox.im application: http://tox.im/en ?
No I have not seen that one before but it looks like it's opensource so I might take closer look. Will se if there's a linux port available already.
@xerxes2,
There is no way a computer can generate a sequence of truly random numbers, so there is no way a computer can implemente a one-time pad.
(the last "." is intended to mean: "full stop".)
dschoepe
2014-01-02, 16:07
I think it would be a good idea to try and port these apps to whatever device you have in mind, as they are open-source and many skilled people looked at them, as far as I know:
https://whispersystems.org/
s/closed source/proprietary algorithm
Having worked for a crypto company myself (although not involved in the actual crypto stuff, so no tricky questions please, I am not an expert), I would have no problem using a commercial, closed-source application - as long as the actual algorithm is published. It is the guys that invent their own algorithms that I have no trust for. Security through obscurity is the least reliable kind.
In that case you still have to trust that the company didn't make any mistakes in implementing and/or using the algorithm. As others have said, even if you use an algorithm that is believed to be secure, it's very hard to use it in a secure manner with the right protocols, etc.. If you have an open-source application, a lot more people will (hopefully) check the code for this kind of mistakes.
(And this is all under the optimistic assumption that the company is not malicious or coerced to insert backdoors by some intelligence agency.)
biketool
2014-01-02, 16:07
Reinob,
If the computer takes a truly random seed, say a bare CCD facing a mildly radioactive object or even the input of the camera as the user randomly waves it around and you can get one time pad level seeding as good and probably far better than rolling dice or picking lottery number balls.
Reinob,
If the computer takes a truly random seed, say a bare CCD facing a mildly radioactive object or even the input of the camera as the user randomly waves it around and you can get one time pad level seeding as good and probably far better than rolling dice or picking lottery number balls.
1) OP is talking "app", as in smartphone-app.
2) this is seriously unrealistic. The receiving party needs to have the password in order to decrypt the message (we're talking symmetric encryption).
you'd need to (externally) generate the sequence, send it over to your partner (*not* from phone) and then somehow make the app use that sequence ("please type your message", "please type your 5087-character password"). As soon as the user types the password you've lost already.
OTP is a theoretical construct. Like a Turing machine if you like. You can talk about it, you can use to model stuff, to gain information about stuff. You just can't build it.
OTP is a theoretical construct. Like a Turing machine if you like. You can talk about it, you can use to model stuff, to gain information about stuff. You just can't build it.
Not quite. You can pre-generate say a thousand OTPs and give them to both parties, then use (and destroy) them one by one. In case of secure SMS, the OTPs have a finite length so not even too much resources spent. Of course keeping a bunch of OTPs for future use has its own problems but at least it is doable.
> unbreakable like Vigenere is
Please stop saying this. Vigenere is breakable. What you are describing is more correctly referred to as a one time pad (as other have suggested) .
There are a number of problems with implementing effective one time pad solutions, e.g.
1) securely communicating the key to the recipient
2) key must be kept secure
2) key must only be used once
3) key must be completely random
4) key must be at least as long as the message
Basically, as Steve Bellini (https://www.cs.columbia.edu/~smb/informal-bio.html)said: "As a practical person, I've observed that one-time pads are theoretically unbreakable, but practically very weak. By contrast, conventional ciphers are theoretically breakable, but practically strong."
Not quite. You can pre-generate say a thousand OTPs and give them to both parties, then use (and destroy) them one by one. In case of secure SMS, the OTPs have a finite length so not even too much resources spent. Of course keeping a bunch of OTPs for future use has its own problems but at least it is doable.
It is doable, but only if (as in necessary, not sufficient) the key/password is typed by the user and never pre-stored on the phone. Even with a hardware keyboard like in the N900 you don't want to type 160 (or whatever) additional characters (for which no auto-completion will help, the key being truly random) every time you want to send an SMS.
So, doable in principle, but not in practice. Plus see @strongm above.
dschoepe
2014-01-02, 23:45
It is doable, but only if (as in necessary, not sufficient) the key/password is typed by the user and never pre-stored on the phone.
I don't think we assume the phone to be compromised here, so storing a very long key on the phone in advance and then using it piece by piece is not problematic, if we're only concerned about end-to-end security (i.e. that no malicious base station or similar can read the messages).
If we assume that the attacker also controls the phone anyway, then he can just see the message directly.
To be clear, the idea is still extremely impractical, but password entry should not be the problem.
vBulletin® v3.8.8, Copyright ©2000-2024, vBulletin Solutions, Inc.