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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
