Building Deception Into Encryption Software 106
holy_calamity writes "MIT Technology Review reports on a new cryptosystem designed to protect stolen data against attempts to break encryption by brute force guessing of the password or key. Honey Encryption serves up plausible fake data in response to every incorrect guess of the password. If the attacker does eventually guess correctly, the real data should be lost amongst the crowd of spoof data. Ari Juels, who invented the technique and was previously chief scientist at RSA, is working on software to protect password managers using the technique."
I discovered a long time ago. (Score:1)
I speak in Navajo with a Southern accent.
Re: (Score:2)
Are you sure it isn't Southern with a Navajo accent? They sound very similar.
Re: (Score:2)
Are you sure it isn't Southern with a Navajo accent? They sound very similar.
It's more like the fourteenth amendment with a slight accent of freedom.
I've seen this before (Score:3)
Voyager episode on honey from 1998
http://en.wikipedia.org/wiki/H... [wikipedia.org]
This is more of authentication than encryption... (Score:3, Interesting)
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up? Authentication is another story.
Are they meaning to make a system similar to Phonebookfs? This is an interesting filesystem used with FUSE. You have different layers over the same directory, so one encryption key may allow you to grab one set of files, another key, a different set. Then there is chaff present that cannot be decrypted under any circumstances and provides plausible deniability.
Is something like phonebookfs what they are intending?
Re:This is more of authentication than encryption. (Score:5, Informative)
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up?
Actually, it wasn't murky. That it cannot work for arbitrary data types is spelled out towards the end. This is for data of which the encryption system knows the data type well enough to fake it, and the encryption system has to be built to target the specific data type. The examples given are credit card numbers or passwords.
For instance imagine a password manager that, for every decryption attempt with a wrong master password, returns a different set of bogus but plausible passwords. How would a brute force attack automatically determine which one is the "real" set of passwords of the user, even if it can guess the right password?
Re: (Score:2, Insightful)
This works provided you don't have a known cleartext to test against. So if I had a known credit card or password in the database (by signing up legitimately for a website that uses th is) then I have a method of determining the dataset to be decrypted.
Re:This is more of authentication than encryption. (Score:4, Insightful)
Why would an attacker be using the enemy-provided 'honey' program to try to brute force the decryption?
Surely he'd use a program that isn't known for serving up fake results.
Re: (Score:1)
You could set up the encryption so that any form of operation returns a viable result, ie. base the encryption on a dictionary of words or phrases, markov chains etc. I think of it in terms of this. https://www.cs.cmu.edu/~odonnell/hits09/gentry-homomorphic-encryption.pdf or ECC
Re: (Score:3)
The focus of that research is to allow operations on data that remain encrypted, and where the actual content of the manipulated data is not explicitly known.
That might work for something composed of tables of numbers, bank data, Phone call pen register logs, or passwords as the GP suggests, but not for text.
Humans are very good at determining gibberish from prose, or fragments of color from images. Plausible, but bogus, is a tough nut to crack
where human evaluation is involved.
Re: (Score:2)
That might work for something composed of tables of numbers, bank data, Phone call pen register logs, or passwords as the GP suggests, but not for text.
Humans are very good at determining gibberish from prose, or fragments of color from images. Plausible, but bogus, is a tough nut to crack
where human evaluation is involved.
The whole point of brute-forcing is that you don't need human evaluation. Are you really planning on a human evaluating the results from all 2^128 possible keys? How many universe lifetimes do you have to crack this thing?
Re: (Score:2)
But don't you suppose that computer systems that can distinguish gibberish composed of valid words from meaningful sentences?
There is more than a little research in this area [wikipedia.org].
Re: (Score:2)
It doesn't need to stand up to human scrutiny to foil a brute force or dictionary attack though. The whole point of those attacks is to try a large number of keys quickly, and human oversight would make the process too slow to be of any use.
Re: (Score:2)
Think of it as ROT-n encryption of random data, where n is the key
If you choose the wrong n, you'll still get blob of random data back, just not the correct one.
Now, the tricky part is in making sure the incorrect keys returns data that's hard to distinguish (meaning it can't be done automatically and/or quickly) from the correct plain text, when the plain text ISN'T random looking, but something like passwords, SSN, credit card numbers.
Re: (Score:2)
The crooks would use their own decoder to get at the internal encryption algorithm, skipping the "oop, fail, generate plausible password" wrapper.
Re: (Score:2, Informative)
No, the idea is that the protection is built into the algorithm itself. Rolling your own decryptor would spit out the same fake info for the same key. To balance this out, the algorithm works only for limited types of data.
Re: (Score:2)
If you are setting it up, you could have discreet records individually encrypted. One row correctly encrypted and (some number) of rows of fake data encrypted with a false key. Without knowing which row is good and which row is bad, an attacker would get (some number) of potential keys that return realistic but wrong data. They wouldn't need to run my decryption routines to generate these false positives.
Re:This is more of authentication than encryption. (Score:5, Interesting)
Consider a case of a credit card number. A CC# consists of 15 digits plus a check digit for 16 digits total.
Now, in encrypting, validate the check digit and then drop it. Take the remaining 15 digits and express them as a binary value. It should be around 50 bits. XOR it against a 50-bit mask, and that will be your ciphertext value.
To decrypt, XOR against that same value and recompute the check digit.
Any incorrect value will produce a number that passes basic validation (as long as it doesn't exceed 2^15).
For bonus points, you can probably encode the first digit in only 2 bits, because most cards begin with 3, 4, 5 or 6, depending on the issuer.
Now, is this a good encryption scheme? Maybe not, but it does at least demonstrate the concept.
Re: (Score:2)
I put up the oversimplified example because people were not even getting the undlying concept behind the undlying concept behind the undlying concept behind the undlying concept.
Re: (Score:3)
I think the point is that the encryption algorithms themselves are incapable of producing anything that does not look like a 'real' result. For instance, if you have a credit card number you could encypt is as just a series of characters. But that makes it easy to determine which keys are wrong, because decrypting with them would return something other than a string of 16 digits. But what if you treated those 16 digits as a number and encrypted it as such? Then, no matter what key was tried, you would
Re: (Score:2)
As was pointed out, this requires the encryption/decryption process to know how a credit card works and what makes one valid or invalid.
...and/or for the cleartext to include many more fake but valid-looking results than valid results, among which only the correct key picks the valid results and invalid keys pick incorrect results. That requires that invalid but plausible results are either easy to fabricate or can be fabricated offline rather than in realtime. Under certain circumstances, partial exposure of correct results, mixed in fake results, might even be desireable
Re: (Score:2)
There are no 'fakes'. Every decryption produces a number that could be a credit card number (ie has the right format and passes the tests for number correctness). This is not a pre-generated 'fake', it is just the result of running the decryption algorithm with the wrong key.
As an example I gave elsewhere - generate a random block of data (/dev/random or whatever). Encrypt it with whatever algorithm you want. Now decrypt it with the wrong key. Can you tell (without looking at the cleartext) that the dec
Re: (Score:2)
The two solutions (algorithmically ensconced or via companion fake data) are basically equivalent, because everything that is not part of the true cleartext is part of the algorithm. This is an implementation detail.
Re: (Score:2)
Re: (Score:2)
But even that requires that the human have an easy way to tell whether the result returned was valid. In the case of a password, this may be simple, but relatively time consuming...or it may be difficult. Of course, in other circumstances, it could automatically try the result against a test, and quickly determine whether or not it was correct.
Re: (Score:2)
Your assumption also means that the underlying encryption is an unknown algorithm and you have no access to the actual encrypted data. There has to be something else to keep you from attempting to decrypt the data without using the password manager it was made with.
Re: (Score:3)
No. Consider this: today encryption algorithms work on binary data (bytes). Suppose I generate a random block of binary data, and encrypt is using whatever well-known algorithm you tell me to use. I give you the encrypted output. Can you tell what key was used to perform the encryption, or tell me what the original data was? No, because no matter what key you use you will always get back a random block of data, so which is the 'correct' data?
Now suppose, instead of using an algorithm that can encrypt
Re: (Score:2)
Possibly with a credit card a 16 digit number all decryption returns a 16 digit number however credit cards aren't random numbers there are rules to how they are formed. Just like alpha numeric passwords are still likely to resemble a word or phrase.
Re: (Score:2)
That is not the point though. The point is that domain-specific encryption could be harder to brute-force than generic encryption that can produce results which are obviously false. So a credit card isn't just 16 random digits - so what? What is not random - the issuer ID and the check digit (there well be more, it does not matter). So treat those 'non-random' parts differently. Don't even bother storing the checksum, recalculate it when returing the result. The checksum will always be right then. Th
Re: (Score:2)
As a broad theory it works but in practice.... there is a lot to take into account we will just have to wait and see.
Re: (Score:3)
TFA was murky, but generating bogus data? If one is brute forcing a data blob, how can it make stuff up? Authentication is another story.
It didn't seem all that murky:
. But he notes that not every type of data will be easy to protect this way since it’s not always possible to know the encrypted data in enough detail to produce believable fakes. “Not all authentication or encryption systems yield themselves to being ‘honeyed.’”
So it only works with data where it can generate believable fake data -- like credit card numbers or passwords.
Re:This is more of authentication than encryption. (Score:4, Interesting)
Many a years ago I had a phone that included a password storage application. You gave it a 4 digit pin and it would show you a checkword, then list all your passwords (key->value). If the pin was wrong, it would still give you a checkword, but different from what your correct word get and then list all the same keys, but different passwords.
Was a pretty nice application, but can't remember the make of the phone, probably a Sony-Ericsson.
Re: (Score:2)
Re: (Score:2)
The checkword, you put in your pin when you set the application up, it shows you "banana" (or car or pink or whatever maps to your pin - obviously the wordlist needs to be shuffled during install so no two installs has the same mapping).
Next time you use it and you put in a wrong pin, it will say "apple". You know it's supposed to say banana so you know you put your pin wrong, your adversary (the guy just stole your phone), doesn't know the checkword so he wont know if it's right or wrong.
Re: (Score:2)
interesting idea (Score:1)
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
Re:interesting idea (Score:4, Interesting)
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
Re: (Score:2)
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
What's the goal here - to make the returned data "not my data", or "incorrect data"? There is a world of difference between these two. "Not my data" is a simple thing to generate, but could still be correct data. IE, if the data protected is a card number, and the generated number matches someone else's card, then do we care or not? The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism
Re: (Score:3)
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
What's the goal here - to make the returned data "not my data", or "incorrect data"? There is a world of difference between these two. "Not my data" is a simple thing to generate, but could still be correct data. IE, if the data protected is a card number, and the generated number matches someone else's card, then do we care or not? The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned. While this wouldn't meet the criminal's goal, it could open a possible DDOS attack vector on the validation service (ie, a brute force becomes a magnified reflection attack).
They aren't going to store a big database of valid credit card numbers so they can return someone else's card number, they'll just generate a random number that looks like it could be a real credit card number and passes the checksum test.
Yes, a criminal could take the credit card numbers from each decryption attempt and test them, but if he's willing to test millions of card numbers to look for a valid one, he could just generate the card numbers directly and not attempt the decryption in the first place.
Re: (Score:2)
So you decrypt something and it *looks* like real data.
So it would have to be a function that produces 'good' results and 'bad results' but the bad results look like good ones.
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
If randomly generated "fake" data matches someone else's password (or whatever is being encrypted), that other person didn't use a strong enough password. This system is just acting like a hash function -- criminal tries password A and he decrypts the data to some string, then he tries password B and the data gets decrypted to another string. If those randomly generated strings happen to match someone elses password on the system, the criminal could have saved himself some time by generating the password guesses himself.
What's the goal here - to make the returned data "not my data", or "incorrect data"? There is a world of difference between these two. "Not my data" is a simple thing to generate, but could still be correct data. IE, if the data protected is a card number, and the generated number matches someone else's card, then do we care or not? The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned. While this wouldn't meet the criminal's goal, it could open a possible DDOS attack vector on the validation service (ie, a brute force becomes a magnified reflection attack).
They aren't going to store a big database of valid credit card numbers so they can return someone else's card number, they'll just generate a random number that looks like it could be a real credit card number and passes the checksum test.
Yes, a criminal could take the credit card numbers from each decryption attempt and test them, but if he's willing to test millions of card numbers to look for a valid one, he could just generate the card numbers directly and not attempt the decryption in the first place.
If we're simply returning a random string that "looks" valid, then this method of protection works. If we return a known invalid number, then we now have a test that the attacker can use to validate the password input. It does take one additional step (validate the result).
Re:interesting idea (Score:4, Informative)
The criminal doesn't care, as long as their goal is met (get a valid card - it doesn't have to be yours). If we're talking about "invalid" data, then we need some mechanism to validate the generated data before it's returned.
If you are worried about a random credit card generating algorithm generating real credit card numbers via this method, you should be just as worried about attackers using the same random number generator on their own!
Re: (Score:2)
Help me understand this. If the 'wrong' results are truly random data that happens to look correct (as decrypting with the wrong key should be), then how does a match imply that a chosen password was weak? If the data is random isn't it equally as likely that any string would come up as a possible password? Why would a 'weak' password be more likely to come up than a 'strong' password?
Also, what would be the problem if the random password does match some elses? If your password is 'xyz', and I try passw
Re: (Score:2)
Help me understand this. If the 'wrong' results are truly random data that happens to look correct (as decrypting with the wrong key should be), then how does a match imply that a chosen password was weak? If the data is random isn't it equally as likely that any string would come up as a possible password? Why would a 'weak' password be more likely to come up than a 'strong' password?
Also, what would be the problem if the random password does match some elses? If your password is 'xyz', and I try password 'xyz' on my userid, it doesn't magically give me access to your account.
I think you'll have to go back to the post before me, he's the one that said:
Would have to be careful that the 'bad' results do not do things like open the lock though. For instant in the case of login list breaches.
Statistically speaking, if a randomly (or pseudorandomly) computed string matches someone else's password, then his password was not safe in the first place. A weak password is more likely to come up by an algorithm that's generating "plausible" passwords than a strong one, because a weak password is weak because it's easy to guess. That could be because it has a small keyspace (i.e. a 4 digit PIN only has 10,000 possible choices,
Re: (Score:2)
Yes, I understand that an easy to guess password is weak. What I don't understand is the assertion that a randomly appearing password indicates that the password is weak. A randomly appearing password has equal chance of coming up 'd$a8%zyq' as it does 'password'. If my password was in fact 'd$a8%zyq' why would it be considered weak?
The decrypter is not generating 'plausible' passwords, it is generating 'possible' passwords. If someone is trying to break in using weak passwords they are not going to be
Also willing to take the NSA paycheck? (Score:2)
Security through obscurity (Score:2)
I guess it DOES have some benefit, huh?
Re:Security through obscurity (Score:4, Insightful)
I guess it DOES have some benefit, huh?
People misunderstand what "security through obscurity" means. Most (all?) encryption relies on security through obscurity at some level.
Hiding your house key under a loose floorboard in your back deck is the kind of security through obscurity that can really work, assuming that there are no other clues that lead to the hiding place. However, hiding the prybar that you use to pry up the floorboard under the belief that hiding the method of access makes your key safer is not the kind of obscurity that works because if the attacker can find your hiding place, he can figure another way to get to the key.
Similarly, hiding or not writing down your password is security through obscurity that works. But trying to hide the implementation details of your cipher algorithm does not, because cryptoanalysis can break your encryption even without access to your encryption algorithm.
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
Re: (Score:3)
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
Like hiding a needle in a needlestack.
I, for one, like the concept, and am anxious to see what impact it could have on modern cryptography.
Re: (Score:2)
If an attacker used software to make 10,000 attempts to decrypt a credit card number, for example, they would get back 10,000 different fake credit card numbers. “Each decryption is going to look plausible,”
This isn't done already???? I thought this was done all along with passwords and other short strings. I could see it being more difficult when the data is human generated passwords due to the bias in selecting words>syllables>numbers>punctuation, but still.
Re: (Score:2)
If an attacker used software to make 10,000 attempts to decrypt a credit card number, for example, they would get back 10,000 different fake credit card numbers. “Each decryption is going to look plausible,”
This isn't done already???? I thought this was done all along with passwords and other short strings. I could see it being more difficult when the data is human generated passwords due to the bias in selecting words>syllables>numbers>punctuation, but still.
No, it's not normally done today. Generally if you try to decrypt a file using the wrong decryption key you'll either get random looking data, or no data at all.
Returning random data is not the same as returning a plausible (but incorrect) password since random data will include all sorts of non-printable characters that few users would include in a password. LIkewise, credit card numbers follow a set pattern with known prefixes and a checksum so an attacker could quickly weed out invalid numbers.
Re: (Score:2)
I guess it DOES have some benefit, huh?
People misunderstand what "security through obscurity" means. Most (all?) encryption relies on security through obscurity at some level.
Hiding your house key under a loose floorboard in your back deck is the kind of security through obscurity that can really work, assuming that there are no other clues that lead to the hiding place. However, hiding the prybar that you use to pry up the floorboard under the belief that hiding the method of access makes your key safer is not the kind of obscurity that works because if the attacker can find your hiding place, he can figure another way to get to the key.
Similarly, hiding or not writing down your password is security through obscurity that works. But trying to hide the implementation details of your cipher algorithm does not, because cryptoanalysis can break your encryption even without access to your encryption algorithm.
So, obscuring your real password among an endless number of fake passwords is the kind of obscurity that can work -- even if the attacker knows that your password is somewhere among the billions of fake ones, unless he has some clue to tell him what your real password looks like, just knowing that fakes are there doesn't help him.
Of course, they could use the prybar to simply break a window, or pry open the door, invalidating the purpose of the hiding place entirely. So hiding the prybar, while it doesn't directly affect the hiding space, helps increase overall security of the system.
Re: (Score:2)
People misunderstand what "security through obscurity" means.
Actually chalk that one on RSA who pushed the security through obscurity meme really hard in the late 90s
Most (all?) encryption relies on security through obscurity at some level.
Of course, starting with your private key, which you should keep secret, continuing with which of your servers holds the motherload, which port you should contact, what exact version of crypto you are using (among the many considered reliable), etc. Each one of these is yet another hurdle on the way of a potential codebreaker attack.
Re: (Score:1)
No, there's a difference between 'obscure' and 'secret'.
Something which is 'obscure' is publicly visible with sufficient effort, but you're relying on people not taking that effort to keep it unknown.
Something which is 'secret' is privately held information which isn't publicly visible, even if someone is looking for it.
Your private key is a 'secret', and should be kept that way.
The selection of encryption algorithm to be used is public, but may be 'obscure' for some indeterminate period of time.
The problem
Re: (Score:2)
I doubt it. That may have been true back when people used substitution ciphers and encrypted plain text. Today's ciphers scramble large blocks and precompress to increase data entropy. I seriously doubt anybody but a top-notch cryptoanalyst can decrypt even the simplest attempt at a cipher from anybody who knows anything at all about cipher design.
Such a cryptoanalyst is likely to be found only at some high level governm
Re: (Score:2)
This is the "bad" sort of security through obscurity, because its sole protection is that noone will care enough to try breaking your encryption cipher. its similar to turning off wifi beaconing or using MAC authentication on unencrypted wifi.
Re: (Score:2)
It's not "no one", it's "no one who is able to break it". There is a big difference. When there is only a handful of people in the world who are capable of breaking your cipher, and there is no chance of them taking an interest it, I'd say your cipher is pretty damn secure.
Re: (Score:2)
I doubt it. That may have been true back when people used substitution ciphers and encrypted plain text. Today's ciphers scramble large blocks and precompress to increase data entropy. I seriously doubt anybody but a top-notch cryptoanalyst can decrypt even the simplest attempt at a cipher from anybody who knows anything at all about cipher design.
Such a cryptoanalyst is likely to be found only at some high level government agency like the NSA and he will likely be too busy to spare any time to decrypt your inane emails to your mistress. Consequently, I would postulate that if you design your own cipher and avoid becoming the next Snowden, your data will be just as safe as if you had used AES.
Which is how we end up with things like the weak Zip File [microsoft.com] and early MS-Office [iacr.org] encryption. Companies think they can roll their own, or take shortcuts and end up with weak security.
Published algorithms have withstood scrutiny by actual experts, don't assume that your home-grown super-secret encryption will stand up to scrutiny - it may leave patterns in the data that can be exploited to decypt it [cryptochallenge.com]
Re: (Score:2)
Which is how we end up with things like the weak Zip File and early MS-Office encryption. Companies think they can roll their own, or take shortcuts and end up with weak security. Published algorithms have withstood scrutiny by actual experts, don't assume that your home-grown super-secret encryption will stand up to scrutiny
Funny you mentioning Zip and Office encryption. Neither of those ciphers is broken. If you read the papers you are linking to you'll find that the zip attack exploits its byte-by-byte CBC mode. With only a byte, dependencies between sequential bytes can be put into a solvable matrix. Expanding the block to even 4 bytes would make this attack infeasible. Office encryption break likewise exploits the CBC weakness, due to Office reusing IVs. The cipher, RC4, happens to be one of your published algorithms. This
Re: (Score:2)
I think perhaps a clearer line to draw would be: Good crypto-systems are based on an algorithm which is known publicly (and can be assessed for strength), plus a secret key which is easily alterable (in case of a leak, new or removed partner, etc.) Thinking that you can keep secret part of the fixed, unchangeable infrastructure is the mistake that "security through obscurity" is meant to warn against. Murkiness about which part is which is bad.
Fake info generation to stop intrusive phone apps (Score:5, Interesting)
I'd been looking into this in a slightly different context. Recently, at Hacker Dojo, someone demonstrated an Android mod to me which dealt with applications that demand too many privileges. It has the usual "disable privileges" option, but for apps that won't run with privileges disabled, it sends fake info.
The demo showed generation of fake phone serial numbers and such. That's easy. Apps that improperly try to upload your address book, though, require generation of a plausible, but fake, address book. That's wasn't in the demo, but it's worth doing. Location data should probably be sent as a random walk from some random starting point.
If enough people do this, it will garbage marketing databases.
Re: (Score:2)
Are you talking about [Open]PDroid? I ask because if there's another mod that does the same thing, I might want to look into it. :)
Re:Fake info generation to stop intrusive phone ap (Score:5, Informative)
Re: (Score:2)
Oh, that looks interesting. If my Nexus 5 ever gets here (stupid winter storms...) I'll definitely want to be read up on that.
Thanks!
Re: (Score:2)
I do lots of similar work when generating test data. It's pretty common to have libraries for things like "make up a plausible address" or "randomly generate a credit card number." Extreme cases can generate whole narratives, even intentionally injecting spelling and grammar errors at varying rates in order to fool packages that use lexical analysis to detect robot text.
The work that spammers have done attempting to fool email filters is probably directly applicable to this effort.
Re: (Score:2)
Re: (Score:2)
Because awesome.
How does the decrypter know what to send out? (Score:3)
If the software is detecting that the key is bad then all the attacker has to do is use software that doesn't do this. This assumes that the attacker has direct access to the file. If not, then well known throttling techniques apply and the new wrinkle doesn't buy much.
Making bogus data come out without requiring specific software for decryption seems like a very hard problem. Every data type will need, not just unique software but unique encryption algorithms that are both secure and not trivial extensions to known algorithms.
Compression could do this (Score:2)
Bad form, I know, to respond to your own posting. But it occurs to me that data specific compression could accomplish the goal. Credit card numbers have structure. If you create a mapping between only valid card numbers and the minimum number of bits then encrypt that then it doesn't matter how the data is decrypted. It always produces valid looking credit card numbers. The catch, though, is that the bit mapping needs to be exact. If the total possible credit card numbers is not a power of 2 then ther
Re: (Score:1)
Sounds to me this is more of an approach rather than a specific implementation. TFA talks about specific data types, such as credit card numbers and passwords. Reading between the lines, it seems like something that would be set up with input from a knowledgeable system administrator or hard-coded for a specific purpose; password manager is specifically mentioned.
So you write this program such that the data type information is not part of the encrypted data but explicitly provided as (for instance) a map
2 easy ways - encrypt fake data or printf(decrypt) (Score:2)
> Making bogus data come out without requiring specific software for decryption seems like a very hard problem.
I can think of ways right off. First, you can encrypt decoy data along with the actual plaintext. It's not that the decryption software CREATES the decoy data, the decoy is already there. Decryption uses part of the key to separate the real data from the decoy.
Given that the data format is known, there's another easy way - packing. Assume the proper format is like social security numbers:
000-0
Re: (Score:2)
It will only work for data that is so well characterized you can find the information theoretic optimal representation for it, i.e., you can bijectively map each message onto the integers mod n so that each integer is equally likely to be seen.
Other than CCNs I can't think of much which satisfies this condition.
fake data 1 / 2,000 incorrect keys (Score:3)
One way we do it is to return a "fake" only occasionally. The person who gets their password wrong is very unlikely to see a fake. On the other hand, a bad guy who is trying out 100,000 possible keys will get 50 fakes.
This works especially well if the bad guy doesn't know it's designed to occasionally generate fakes. He thinks he actually did decrypt passwords, but the list he has is nolonger valid. Maybe it's out of date, he thinks, or maybe they are stored backward, or maybe we KNOW he stole the list a
Similar to deniable encryption... (Score:2)
The goal stated in the article is similar to that of deniable encryption. Whereas "honey encryption" works through a piece of dedicated software, deniable encryption works by constructing a block of ciphertext in such a way that different plausible plaintexts can be recovered depending on which symmetric key is used for decryption. Of course, only the user knows how many different plaintexts are actually buried in the ciphertext, and under duress (rubber hose, point of a gun, etc.) he can relinquish the n
Lorem Ipsum (Score:2)
"Honey Encryption" (Score:2)
Tom Simonite writes at MIT Technology Review that security researcher Ari Juels says that trickery is the missing component from the cryptography protecting sensitive data and proposes a new encryption system with a devious streak. It gives encrypted data an additional layer of protection by serving up fake data in response to every incorrect guess of the password or encryption key [technologyreview.com]. If the attacker does eventually guess correctly, the real data
Ezmo pubmlic tuiolo vueok (Score:1)
Troffle blent murper humph flempto gretch fooma irf pwenty eb wertoo bakk empo flbe ilffy fez mulok.
Very narrow use (Score:2)
The only cases in which this approach can work are those where the distribution of plaintext is known in advance.
Since the algorithms used to generate CCN are largely public one can map the class of apparently valid CCNs (suppose it has n members) bijectively into the integers mod n and assuming the CCNs are uniformly distributed over the apparently valid CCNs (likely) their images in the integers mod n are uniformly distributed. Assume that ENC_k is any standard encryption function (public or private) wi
Bit late to this... (Score:2)
... but I have a life.. ^_^ but i've used it already :(
Couple of points: (I'm thinking less in an individual file encryption issue than to a larger set of encrypted data structure)
In a totally non-knowledgeable fashion would the algorithm or the program access the algorithm create the bogus data?
To me one flaw would be random generation of data. If it was random then using the same false password twice would result in 2 different results (so that password can be ignored) defeating the point of the bogus dat