Popular crypto app uses single-byte XOR and nowt else, hacker says A programmer claims the makers of a popular encryption app have failed to implement its core feature: encryption. The hacker, using the alias NinjaDoge24, analyzed the NQ Vault app, which supposedly encrypts files on smartphones and other gadgets. Ninja claims the software used only XOR (exclusive or) and a single-byte key to …
I can't quite make out what you're saying here. The first 128 bytes (4096 bits) are encrypted, then the rest of the file left in the clear. Bad.
Using XOR is secure, provided the mask is "random". That technique has been used forever. Good (or OK), depending on the mask.
Not sure where the AES128 comes in.
Sounds like a bug in the encryption. Bad, very bad.
Read the linked analysis. The mask used is not random. By some means it converts the password into a single 8-bit "key" (barely deserves to be called a key), and XORs each of the first 128 bytes with that key, a byte at a time. (Basically ECB mode (http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29) which would be crap even with a proper big, random key).
The rest of the file is left in the clear.
This isn't encryption, it's about as good as those invisible ink pens you can buy from the Early Learning Centre.
If you know what the file type is (which you can probably work out pretty easily if most of it isn't encrypted) then the first few bytes are known. Doesn't matter if the mask is random or not, you've got the first few bytes and you didn't even have to brute force them! Hardly secure.
This post has been deleted by its author
"Not sure where the AES128 comes in."
I believe the app makers are saying AES128 is used for messages, contacts, call logs and other things are encrypted using AES with a 128-bit key. But in the hacker's test, a simple PNG file was 'encrypted' using a single byte 'key' and plain XOR. And only the first 128 bytes of the PNG. Bizarre. So maybe images aren't encrypted in any meaningful way?
I've tweaked the story here and there to make it a bit more clearer.
C.
Funny.
I once had a protracted discussion on SO discussing an answer to a question about a good encryption algorithm fit for some purpose. The answer basically only said "just use XOR" and for some reason, I had beef with that.
My interlocutor - not the answer's author, some other high-rep guy - argued that the answer was OK, since OTP is a XOR algorithm, and properly executed OTP is secure.
You'll notice that's a well-known fallacy.
Unfortunately, I was unable to convincingly present my stance, and forced to withdraw from the discussion, as the other person eventually reduced their argument to accusing me of being deceptive, misleading, unprofessional etc.
What I'm getting to is: the chance being of course is too minuscule, it would be highly amusing if the creator of the "encryption" code was actually inspired by that 0-net-vote answer.
Using XOR is secure, provided the mask is "random".
Untrue, for a number of reasons.
First, of course, "secure" is meaningless outside context.
Second, if the mask is reused for another plaintext (including another part of the same input) in a manner an attacker can predict, detect, or guess, then the mask can be removed:
C1 = A xor K
C2 = B xor K
Attacker computes C1 xor C2 and gets A xor B, which has the keystream removed and is generally trivial to decode, particularly if there is any known plaintext. Then given enough of A or B, attacker can retrieve K and decrypt future messages as well.
Third, simply XORing with a keystream provides no message integrity and is vulnerable to e.g. bit-flipping attacks.
Fourth, "random" here is handwaving; nothing can be said about the strength of a stream cipher without knowing the provenance of the keystream. It's certainly not appropriate to make vague claims of security.
"...some hacker convention in Germany archive..."
Yes. The Chaos Computer Club. They've got an archive of presentation videos from conventions recently and years past. Although some are badly videoed in places, there are some wonderful presentations that go into the bit-wise detail of precisely how encryption works. Including the function of the XOR. One even explains the NUONCE and what happens if it's used twice.
For anyone interesting in crypto and wanting to have the basics explained, it's a gold mine.
In fact, for the vulnerabilities, it's beyond the basics.
"Google has been contacted for comment regarding the app's claims."
Have you even taken the time to look at the app's description on Google Play? It doesn't claim a single thing regarding file encryption - it doesn't even claim to do it. Will the Register comment on Darren Pauli's claims about his affair with President Obama?
Most likely they modified it.
But, it clearly says in this (http://www.nq.com/vault) page that photos and videos are encrypted.
"Photos & Videos
They’ll be encrypted and only viewable in Vault when you enter the correct password."
And inside the app, it also says that photos and videos are encrypted.
This post has been deleted by its author
I make the 2ROT-13 joke in just of course, but it's a great escape of how not sticking to the algorithmic methods exactly can work against you. Alternatively, take a Caesar cipher of some plaintext and then do it again, and again. The cipher is no harder to break if performed one or a dozen times, and indeed the superposition of iterations may leave one or more characters in clear text, so even weaker.
The thing that makes 3DES and friends secure isn't the secret algorithm, it's the randomness of the key and applying it perfectly. Some people dismissing XOR, but it's actually absolutely secure if the key is longer than the message, and random.
The thing that makes 3DES and friends secure isn't the secret algorithm, it's the randomness of the key and applying it perfectly.
That's a rather odd thing to say, since DES isn't "secret". Are you trying to express Kerckhoffs's principle - that only the key should be secret (or, equivalently, that everything secret about a cryptosystem is part of the key, and fixed aspects are a weak portion of the key)?
That's a very different claim than the one you're making. DES is relatively strong against differential cryptanalysis, for example, specifically because of the values of its S-boxes - an aspect of cipher design that is independent of the key. And it is relatively weak against linear cryptanalysis for the same reason.
The algorithms used in a cryptosystem do indeed have a very significant effect on the overall security of the system (under a broad threat model). So does the implementation, where things like side-channel attacks can subvert the confidentiality of the cipher.
Some people dismissing XOR, but it's actually absolutely secure if the key is longer than the message, and random.
XOR is simply one of two binary Boolean functions (the other is XNOR, aka equality) that can be used in a stream cipher to combine plaintext and a keystream. It's silly to talk about cryptography with XOR without referring to modern stream-cipher concepts. And "absolutely secure" is rubbish - it's a meaningless term outside context. (And yes, that includes OTPs, which are not "absolutely secure" as commonly described. They're not secure if an attacker gets hold of the pad, for example, or tortures the information out of the recipient. "absolutely secure" does not mean anything.)
First off, several encryption methods been written and tested so there is no longer any reason to invent a new method. The App needs only the GUI. So then, that the writer is stupid is established.
Does anyone remember the copy program for Apple disks called LockSmith? That program protected itself by XOR-ing it's sector data with its byte position in the sector. Pretty simple to see the scheme when you look at a sector that should have been all zero's.
> First off, several encryption methods been written and tested so there is no longer any reason to invent a new method.
Wrong. New attack techniques are developed, faster computers can brute force longer keys and thus new, more resistant, algorithms are needed and longer key lengths are needed.
For instance DES has never been broken (albeit it was weakened my new attacks), but it can be brute-forced in hours today. Equally SHA1 has been weakened by new attack techniques.
Thus neither DES or SHA1 are suitable for their original purposes despite huge evaluation and analysis through their standardisation processes.
This post has been deleted by its author
"it doesn't require any cryptographic knowledge to see that the files are mostly left unencrypted, yet nobody even noticed that."
I think your spot on with your description. I'd add that I suspect the lack of the AES-128 encryption on video and images might also be for performance reasons. Mr Average probably won't be happy if a file takes ages to encrypt/decrypt so only the "important" text files get the full treatment so they "compromised" between security, obfuscation and "user experience".
This post has been deleted by its author
This post has been deleted by its author
"Exactly what does anyone gain using this app?"
They get exactly what it says on the tin. The app encrypts data. You claim to understand the concepts so I find it unusual that you're so confused on the matter, and I'm sorry to say coming across as a bit of an ass in this instance.
Wikipedia defines encryption as "the process of encoding messages or information in such a way that only authorized parties can read it". Now, the phone itself is protected and fully encrypted (admittedly I don't know much about Android and your fancy removable SD cards...) such that someone stealing my phone cannot access the fully encrypted drive at all. I'm confident that my data is properly encrypted from that perspective.
So, this app then has nothing to do with properly encrypting the whole file, since that's already done at another layer. It has everything to do with authorising users on your device but not to that data. For instance, letting your current squeeze look something up on Google while also having pictures of a previous squeeze present and inaccessible from the phone.
I have to say that in this instance, the methods of the app appear to be completely appropriate for the requirements. They certainly should have been upfront about their methods and let people choose between battery life and protection but good design for mobile has to be appropriate design to minimise things like power draw.
This post has been deleted by its author
"Now they are all downvoting me on the basis of being condescending, despite the fact that I only started being condescending, (in this thread), after they had already shown their ignorance."
If you thought you only started to be condescending after your first post, you might want to work on your self-awareness.
My comments in that post were deliberately nonsense, posted just to hide a message that nobody, (except seemingly one person), noticed.
We got it. A single word does not constitute a message. No real information was provided. Key points were not made. Elaboration and arguments were entirely absent. Really, then, you got no more than you deserved.
"except seemingly one person"
jesus christ. with that level of arrogance and assumptions about other people, I would never ever buy a cryptography product that you had coded. it took about 10 seconds to see it, before even reading further.
one doesn't have to be russel crowe in a beautiful mind to see your hidden message.
Yes what a wOnderfUl film thAt is, it REAlly makes me think about Cryptogrhy, yoU kNow whaT i mean?
@1980s_coder: that is fantastic! Do us another one, please!
Getting things like that to work is surprisingly easy in practice. Occasionally you may need to twist the plain text more than you would like. Sometimes things just work out conveniently and you consider yourself lucky.
Contrary to what you might at first assume, there are enough ways of phrasing any given concept to give considerable flexibility and allow both plain text and cipher to appear natural. Re-ordering of the points you wish to make is always another option to allow things to pan out in a seemingly natural manner. Each time you do that, however, you have to ensure the plain text still flows naturally without hopping between disjoint concepts. When other options fail there are also any number of general joining words that can be fitted in to almost any sentence to help out.
Your vocabularly also helps out massively - use a thesaurus if you are having massive difficulties. Often it isn't really necessary and the other approaches allow you to express yourself clearly enough. Unless you have really painted yourself into a corner the inclusion of obscure terms should be avoided where possible. Realistically, however, they may be necessary from time to time. Similes and metaphors are another approach to use sparingly, if you use them to excess the message appears too flowery and poetical.
Eventually, however, you do need to come to the point and make it clearly and unambiguously. Lexicographer's playthings are interesting puzzles but are not an end to themselves.
Finally, always end with something that sounds completely natural - it helps create a better impression of the composition as a whole.
They never claimed it was military grade - its designed to stop your files being copied to another machine and viewed without permission. Its not designed to stop the NSA or the Cartel from viewing your sex tapes.
What is it with security geeks that they think everyone needs AES256 or higher for their personal files?
You don't use a F1 car to go to the shopping centre because its not appropriate, even though its the best form of vehicle technology available.
Time for getting expectation back to reality
The point is that AES256 encryption is freely available to anyone who wants to do encryption, and not using it is just criminal. There is no disadvantage to using AES256, therefore it is _entirely appropriate_ for encryption. This isn't using a Formula 1 car for doing your shopping. This is using your car for shopping, but only driving in reverse gear.
I suspect that the reason they don't do AES-256 is due to performance. And even AES-128 is pretty processor intensive. Not to defend the authors of this app though! They could have done much better, and it makes sense to at least make sure the user is aware of limitations like this if you can't work around them.
As a separate but related point, I am an embedded software engineer implementing on cortex-m series processors... For our purposes AES-128 is perfectly OK and so that is what we use in order to save processor cycles, battery life, etc etc. Saying that there is no place for anything less than AES-256 is a bit of a stretch in my opinion.
This post has been deleted by its author
By the way, you are aware that depending on the scenario, AES-128 or AES-192 may be more appropriate due to weaknesses in the key scheduling, aren't you?
I don't know of any attack on the AES key schedule that 1) improves for larger keys and 2) works against full AES (rather than reduced-round variants). The successful key-schedule attacks against full AES (such as Dassance and Venelli 2012's fault-injection attack) don't appear to improve in the larger-key variants of AES, unless I'm missing something in that paper.
But this isn't a topic I follow closely. Do you have a citation?
Of course there is a disadvantage to using AES256. Processing time for one, and program (application) size for another. To prevent casual snooping by friends & relatives a simple XOR is sufficient for almost all cases. Anyone who needs to hide their terrorist plans from GCHQ forensics should be using something that has been *proven* to have a high grade encryption standard and no backdoors rather than place any reliance on any advertised claims by the application vendor. If a person cannot educate themselves sufficiently to know how to vet an encryption application and also learn about other potential leaks from their OS and storage technology, they should not be handling highly sensitive or illegal data without guidance from someone who can. Heck, mobile phones store data on flash memory, which means that any data that was ever in the device will almost certainly be recoverable from that Flash after it has been encrypted no matter how secure the encryption algorithm, because data in Flash memory is usually not erased or overwritten until the memory device becomes full - it's a lot harder to get rid of old data on a Flash drive than on a conventional HDD, because sectors are dynamically renumbered so the logical sector you are over-writing is not the same physical sector that the data was originally written to, and an application probably does not have access to the physical sectors, because only the hardware Flash controller can address the memory by its physical address. (Also applies to USB memory sticks in a conventional PC).
Would you feel the same way about, say , a front door lock that appears secure because it appears to require a key then you discover that using a certain sequence of knocks, you can open it?
It's the same principle, appearing to be secure.
The fact is that this company are selling a product that appears to offer a secure storage system, and it seems it does not offer what they are selling. Personally, I don't feel the need for these security systems (and, TBH, find them to be more trouble than they are worth), however some people do. Regardless of whether you or I feel we need secure storage, if this product is not secure and they are selling it as such, the company are wrong, and probably liable under the Sale of Goods act.
"Would you feel the same way about, say , a front door lock that appears secure because it appears to require a key then you discover that using a certain sequence of knocks, you can open it?"
There is (was) a certain no-longer-common model of Dell 'business-class' desktop which, like many others, allowed people to set up a BIOS password. However, if you really wanted to get in, and merely hit 'enter' three times in quick succession, you'd be in. It had to be three times quickly, take too long and it didn't work. Hit 'enter' four times and it didn't work. And it had to be the 'enter' key on the numeric keypad, hitting 'return' didn't work. This had to be the silliest backdoor ever set up.
Management at the place where I discovered this was Not Amused(tm). They now use HPs.
Management at the place where I discovered this was Not Amused(tm). They now use HPs.
Vastly Overpaid Monkeys, the lot of them (unless, they really picked HP because of the HP vendors generous hospitality package)!
HP provides iLO baked into their machines, hacking iLO is a lot more fun than poking in a BIOS.
"Would you feel the same way about, say , a front door lock that appears secure because it appears to require a key then you discover that using a certain sequence of knocks, you can open it?
It's the same principle, appearing to be secure."
No, it's more like a small padlock on a bedroom door, behind a very secure front door and alarm system. Nobody can get into the house without authorisation but once inside security doesn't need to be as tight because you already trust them enough to let them in. Your house guest is unlikely to sit there and break the padlock or try to pick the lock because you're there with them. When you're not home they can't get in because they don't have keys to the house.
No you wouldn't use an F1 car to go to the shops because there would be problems - extremely expensive vehicle, no boot, not road legal, no passenger seats, uncomfortable to drive etc. But there is no downside for the consumer to using proper encryption. It's like having a bog standard normal car that you go shopping in which also happens to be able to win F1 races.
"I am getting the grip. Most ARM chips have AES acceleration and libraries to use it."
No they most certainly do not. Of the last 10 ARM CPU's that I have designed into embedded devices, only one had any (claimed) encryption support - and when I tried to use it I discovered that there was a silicon bug that meant that most of its functions did not work. I have implemented software encryption (both DES and AES), which causes a significant hit in file transfer speed.
"
AES is a standard part of the ARMv8-A instruction set. Before then it was non-standard and implemented by only some manufacturers.
"
Unless you are saying that most ARM processors have an ARMv8 core with the optional crypto extension implemented, that fact is irrelevant to my point.
They never claimed it was military grade
It's a fair bet that any text that refers to "military grade" cryptography, except to point out how banal and cliched the phrase is, has nothing to contribute. "Military grade" is a bullshit phrase used by marketers and the ignorant.
... assuming the key is long as the message and random. That's how a one time pad operates.
The problem of course is you still have to store the key somewhere to read the message out again (e.g. between an embassy and its country) and so otp only works in certain scenarios. In a phone it doesn't help at all.
Anyway, this app sounds like snakeoil. It's amazing it's so incompetent - I'm sure that every single phone OS is capable of providing hardware assisted crypto with very little effort at all.
"Bitwise XOR is a completely legit way to encrypt assuming the key is long as the message and random."
And, of course, only used once (hence the name OTP :-)
It also has another useful feature: Complete deniability. You can always prepare a second set of keys that decrypt your dick pics (thank you John Oliver) into cute kitten pics instead. :-)
The One-Time-Pad is the only encryption system proven to be perfectly secure. Furthermore, any other perfectly-secure system must (also proven) be essentially the same as a OTP. Using XOR, the OTP also has deniability since you can change the message simply by changing the key.
NQ Vault is a product of NQ Mobile. A quick bit of searching on them in Google News comes up with allegations that the entire company grossly overstates its user base and income. This is a company where the founder and other senior officers have a habit of abruptly resigning. Draw your own conclusions.
This post has been deleted by its author
"...does it stop your mum or girlfriend from easily looking at stuff on your phone?"
No. Obligatory xkcd:
http://www.xkcd.org/341/
And even someone clueless about tech can think, "hey, there's an encryption app, must be something juicy on here. Maybe I can ask a friendly geek to crack it".
And even someone clueless about tech can think, "hey, there's an encryption app, must be something juicy on here. Maybe I can ask a friendly geek to crack it".
Oh yes in some daring Mission Impossible style switcheroo so the target doesn't notice. Or a race against time to crack the code and get the data before they come back asking where their phone is!
Really? Really?? Come off it.
Poor old XOR. Talk about getting a bad press. It’s not XOR’s fault! When used properly, in a specific circumstance, it gives you unbreakable encryption. Which other humble logic operator can claim such fame?
This app sounds like something a twelve year-old would write when playing/learning about crypto.
Indeed, back in the day, I wrote little programs myself (command line stuff) that did XOR encryption. But my programs at least had the common decency to operate on the entire file….
So don’t blame XOR. XOR is brilliant. XOR is groovy. It even has a cool name.
Yours,
Brian Ignatius Nary,
Chairman and Vice President, The Royal Society for the Appreciation of XOR and Its Wondrous Flipping Versatilities
Going by this company's apparent "expertise" in encryption, I'm expecting them to address the issue by releasing a new "double strength" version that applies the XOR encryption key *twice*.
I'd buy that for a dolla... oh, hang on, no I wouldn't.
XOR takes two inputs and has one output.
You cannot use it twice and end up with the input.
For an output of 1, it would be impossible to know which of the following inputs were used:
0 1
1 0
So you would have a 50/50 chance of "guessing" the inputs.
@Tom Wood; Yep, that's exactly what was meant. Basically just a slight variation of the well-worn joke "so incompetent they don't get why using ROT13 encryption twice [or applying a XOR twice using the same key] doesn't make it twice as strong!!!!!111".
Given I did mention applying the XOR encryption key twice for "double strength" (ahem), I'm not sure what Clive Galway thought I was suggesting...?
"
XOR takes two inputs and has one output.
You cannot use it twice and end up with the input.
"
Except one of the inputs is going to be the same (key) both times.
Of course you can - that's how just about all encryption is carried out at the final stage (with keys that are a tad longer than 8 bits and change from block to block)
if
P xor K = C
then
C xor K = P
AFAIK, Calling XOR the "Exclusive Operator" is technically incorrect and ambiguous. For example, Exclusive NOR is an "Exclusive Operator", but is not XOR (In fact, it is the exact opposite of XOR).
Operator = The operation (OR, AND, NOT etc)
Exclusive = "If both inputs meet the criteria, invert the result".
Certainly, the sentence "and said it used only XOR (exclusive operator) to safeguard files" implies that XOR is THE "exclusive operator", when it is not, it is ONE OF the exclusive operators.
If you said to an engineer "Use an exclusive operator" when meaning "Use a XOR", then the statement would be ambiguous.
Disclaimer: I am not an expert in this field, so I could be wrong about accepted terminology.
</pedant>
Am disappointed in The Register for the quality of this article, "Exclusive Operator" is but one example. Expect one to be more fluent in digital technology.
Counter Mode for converting a block cipher such as AES into a streaming cipher encrypts a known text such as a counter (or disk sector number) then XOR's that with the data to protect. One beauty of this technique is that encrypting is exactly the same process as decrypting, run it right back through the exact same routines. Its good enough for the NSA.
Back in the day, WordPerfect used XOR encryption. A key was created by XOR-ing the password onto itself with right-shifts('ABC' -> (SLR ((SLR 'A') XOR B)) XOR C), then the text of the file was encrypted with a running XOR against the password. The key served to reject obviously wrong passwords. In 5.1, you had a sequence of a dozen or so null or space bytes following the key: for short passwords there was no point in even checking the key.
Sendero Luminoso naively trusted in the security of WordPerfect's encryption, with disastrous results when one of their safe houses was raided.
But from a crypto perspective this is the same thing that is happening even with accepted crypto methods like AES.
It all come down to entropy being the 'limiting reactant', if you will, to your information security. There was a study published a few months ago on MIT Technology Review on this subject - the gist is that regardless of the level of obfuscation provided by the crypto algorithm, the level of security is directly related to the key size. Math crypto like that currently in use had some bad assumptions about how the entropy got weaved into the ciphertext.
The bottom line is that this ridiculous tool that everyone is mocking for using an 8 bit key is only slightly less secure than 4096 bit AES, especially when you are streaming data.. after capturing 4K bits you have almost all you need to start breaking down the crypto.. it comes down to searching a much (much!) smaller keyspace than what the crypto theory tells you there is.
These systems are broken at a fundamental level.
"You may laugh ...
... The bottom line is that this ridiculous tool that everyone is mocking for using an 8 bit key is only slightly less secure than 4096 bit AES, especially when you are streaming data.. after capturing 4K bits you have almost all you need to start breaking down the crypto..."
Believe me, I'm laughing.
XOR is a bitwise operation common in crypto algorithms, but it offers little when it is used in isolation and certainly when used with a fixed single-byte key.
Strike "single-byte". The length of the keystream doesn't really matter, if a stream cipher (which is what this is) uses the same keystream for different plaintexts. It's the "fixed" that makes this system useless against anything other than trivial threats.
An attacker who knows the keystream has been reused and knows or can guess anything about the structure of the plaintext can easily remove the keystream by XORing two ciphertexts at different offsets until the result is (with some decent probability) two plaintexts XORed together. Cryptanalysis 101.
Yes. The Chaos Computer Club. They've got an archive of presentation videos from conventions recently and years past. Although some are badly videoed in places, there are some wonderful presentations that go into the bit-wise detail of precisely how encryption works. Including the function of the XOR. One even explains the NUONCE and what happens if it's used twice.
For anyone interesting in crypto and wanting to have the basics explained, it's a gold mine.
In fact, for the vulnerabilities, it's beyond the basics.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
