Slashdot Mirror
Building Deception Into Encryption Software
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 speak in Navajo with a Southern accent.
Voyager episode on honey from 1998
http://en.wikipedia.org/wiki/H...
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?
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.
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?
Great so long as he isn't also willing to take the NSA paycheck.
Just guessing but if it's aimed at protecting password managers it'll only be a small amount of data, so the flow could be:
generate N sets of fake data and fake passwords for a similar structure to the real data and password; encrypt each set of data with its own password; merge the resulting data. Now when you try any password it'll show the related set of data clearly, but with a huge amount of gibberish surrounding it. Sooner or later the correct password fror the real data will be used but the attacker won't know that it's really the real one.
I guess it DOES have some benefit, huh?
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.
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.
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.
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.
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.
No sig today...
The crooks would use their own decoder to get at the internal encryption algorithm, skipping the "oop, fail, generate plausible password" wrapper.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
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. :)
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
How does the correct user who enters an incorrect password recognize his mistake? Could be funny
A comedy of errors coming to a computer near you.....
There is XPrivacy, which uses the XPosed framework. That doesn't disable permissions, but rather sends fake data to the app.
Sure I sold you robot insurance. But you were attacked by a cyborg. Not covered.
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.
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!
I see it as a plausible approach, since a automated brute force attack will stop whenever it thinks it hits the right pw, requiring human intervention to determine it is bogus. After a few thousand bogus hits, I think that human might just get tired of hitting the NEXT button.
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.
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.
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 also get back a valid number which could be represented as 16 digits, so you have no way of knowing which is the real answer.
That's mostly correct, but a credit card number is actually only 15 digits with a 16th digit that is used as a checksum. Therefore, you'd have to discard the checksum digit and encrypt only the 15 digits that matter; decrypting it would produce a 15-digit number and the decryption algorithm would need to regenerate the checksum digit. That way, any attempt to decrypt would result in a potentially-valid credit card number, but only the correct decryption key would result in the correct number.
As was pointed out, this requires the encryption/decryption process to know how a credit card works and what makes one valid or invalid.
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 non-incriminating plaintext and claim innocence.
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.
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.
www.wavefront-av.com
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.
When they create an encryption program they normally use a precise type of algorithm example: RSA128, RCx, IDEA, etc. When hacker want to decrypt a data file with brute force. They already know the encryption method used. So they can use another "home" program with the same algorithm instead of the "official program". So why they do not use more then one algorithm? With modern computer power, they can use many different type of cryptography algorithm in an "random" sequences! Example : Plain Data --> AlgoA --> AlgoR --> AlgoB --> AlgoZ --> AlgoT --> AlgoW --> AlgoA --> AlgoB --> AlgoG --> AlgoK --> encrypted data. The user have 2 thing to remember, The "key" and the "algorithm sequence" (in this case "A+R+B+Z+T+W+A+B+G+K") So, if you do not have the right sequence of algorithm used. You multiply the computing time to decrypt (brut force) the stolen data.
If he wants verisimilitude he should program it to cough up the plausibility only after 'X' (large random number) tries.
Verbing of nouns weirds the language.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
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 (and thus decrypt) and random binary data I use an algorithm that can only encrypt/decrypt a credit card number or a password. No matter what key you try to use to decode, you will always get something that looks like a credit card number or password. You can know the algoritm, and you can have the encrypted data, and you still have no way of knowing which key is correct because all the results look the same.
Fake data is an old idea: "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."
Excuse me, but please get off my Pennisetum Clandestinum, eh!
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 there will always be decryption failures that produces detectably invalid results.
> 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-00-0000
What you want to avoid is letting the attacker recognize from the format that 571-22-5557 is correct, while jdksfs8fgh is not. To do that, before encryption, pack the data. That means you strip out the hyphens and save the numbers as one byte per pair of digits (or even 6 bits per digit). So the actual decryption returns unformatted, random looking bytes. Those are then formatted using something like printf() to make the actual source plaintext. If the right key is used, they'll be unformatted bytes until printf is run. If the wrong key is used, again you get unformatted bytes until printf formats them. The output comes out in the same format whether the key is correct or not. In incorrect key will result in invalid data that looks just like valid data.
Great idea! Except that it looks exactly like what professional crackpot David A. Scott used to propagate endlessly on sci.crypt back in the late 90s ...
So let me get this straight... The brute force password decryption yields plausible looking passwords on every failed attempt... so, that means the brute force attacker would require some form of test to determine if the plausible passwords are correct, like, say, using said password to log in to it's destination account?
How would a brute force attack automatically determine which one is the "real" set of passwords of the user
Simple, if your attempted crack produces >5% of passwords equal to '123456' then you have found the right one.
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.
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.
Sig Battery depleted. Reverting to safe mode.
Because awesome.
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
"Honey Encryption" to Bamboozle Attackers with Fake Secrets
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. If the attacker does eventually guess correctly, the real data should be lost amongst the crowd of spoof data. The new approach could be valuable given how frequently large encrypted stashes of sensitive data fall into the hands of criminals. Some 150 million usernames and passwords were taken from Adobe servers in October 2013, for example. If an attacker uses 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," says Juels. "The attacker has no way to distinguish a priori which is correct." Juels previously worked with Ron Rivest, the "R" in RSA, to develop a system called Honey Words to protect password databases by also stuffing them with false passwords. Juels says that by now enough password dumps have leaked online to make it possible to create fakes that accurately mimic collections of real passwords and is currently working on creating the fake password vault generator needed for Honey Encryption to be used to protect password managers. This generator will draw on data from a small collection of leaked password manager vaults, several large collections of leaked passwords, and a model of real-world password use built into a powerful password cracker. "Honeywords and honey-encryption represent some of the first steps toward the principled use of decoys, a time-honored and increasingly important defense in a world of frequent, sophisticated, and damaging security breaches."
I just want to know... if this "random decryption" holds up to an attacker's anonymous, single use, non-random oracle...
Sure, if I compromise the database, and every decryption attempt looks valid...I'm going to have a hard time.
But I'm a competent attacker-- presumably I'm free to submit my, or someone else's legit CCard into the system, or cross reference a single (or more) known good cards.
Once I hack the whole database, I now have an oracle to verify the correct decryption against. Unless there's a different key for every entry, I know just have to look up my known good card and it's game over to see if the decryption worked.
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 and therefore we've changed all of the passwords. It was entertaining to read the cracker message boards when we first introduced that feature.
Now, the crackers who keep themselves informed know that we generate fakes, and it annoys them greatly. They don't yet know that we do TWO levels of fakes. A certain percentage of the fakes pass their extra level of checking they now have to do to weed out the fakes. In other words, they THINK they are weeding out the fakes, but they are actually only weeding out the level 1 fakes.
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
Someone had to do it.
Troffle blent murper humph flempto gretch fooma irf pwenty eb wertoo bakk empo flbe ilffy fez mulok.
Table-ized A.I.
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. There are more issuer IDs than issuers? So store the issuer ID as something other than the actual number.
As for passwords, this is not to prevent poor password choices. If good passwords are enforced, then the 'likely to resemble a word or phrase' doesn't apply.
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 decryption used the wrong key? No, of course not, random data looks like random data. That is because no matter what key you use valid-looking data will be returned. Now use an algorithm that can only encrypt/decrypt credit card numbers, and you have the same thing. Every decryption will look like a credit card number.
Note that some of the generated numbers may actually BE valid credit card numbers. That does not matter as long as it is not the credit card number associated with the name on the card, etc.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
The NSA realises that most people who use encryption have a very poor grasp of logic, and can therefore be carefully fooled into moving from good security practises and towards systems fully compromised by NSA activity. Call this the FUD propaganda method.
An example. The NSA funded pseudo-science papers, and paid to have these papers published in peer-reviewed journals, stating that erased data on hard-drives could be recovered by sufficiently expert forensic labs. Such claims were utterly laughable. Essentially, the NSA had their agents claim that the capacity of any HDD was effectively infinite, because after wiping the current data with a new set of random data, both the new data AND the original data could be recovered.
To an alpha, such nonsense is hysterically funny, but to most betas, the idea of NSA level personnel having some magic 'magnetic surface scanner' 'recreating' all that erased data seems plausible. The goal of the NSA was to discourage people from using the ONLY safe form of erasing procedure (complete over-write with random data), and instead to rely on tools from companies like Microsoft, Norton etc., that only APPEAR to erase data, but actually either simply flag the data, or use a procedure that allows the firmware of the HDD to effectively ignore the erase instruction.
ANY 'magic' complicated security procedure from people with long associations with the NSA (like Ari Juels) is a simple obvious NSA ploy. The NSA has been paying a LOT of money to have Truecrypt attacked in print recently. No brute force attack can work against Truecrypt if a decent password phrase is chosen- so what is this nonsense about wanting 'security' if a brute-force attack cracks the password? And if a successful attack CANNOT recognise the decrypted data as the data desired, you have what is known as DOUBLE encryption (an encrypted container within an encrypted container), which against the 'common sense' of betas, is actually a highly flawed method to safely encrypt data.
PS the container within a container method used sometimes by Truecrypt users is NOT an example of double encryption, but an example of attempting to hide the use of encryption- a very different concept.
One problem is if birth dates are available. One could check if the SSN would have been issued that birthday. Probably doable even if separate keys where used for the birth dates and SSNs but it would slow and complicate the attack.
They don't yet know that we do TWO levels of fakes.
Well, they do now.
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?
"City hall" in German is "Rathaus" Kinda explains a few things......
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.
Sig Battery depleted. Reverting to safe mode.
I understand what you're saying, but what I was getting at with the reference to gentry and ECC are that operations on encrypted data bring you to another step. So, if instead of stepping through a homomorphism or a binary group for ECC, you could step through combinations of a markov chain. This was all to tell the parent that the 'honey' program and fake data are baked into the algorithm, so its not about using a program that returns fake data when you give the wrong passphrase/key.
I see only one problem - Assuming I got the PIN wrong, how am I supposed to make out if it is showing me the 'wrong'/'fake' passwords ?
Here is an open conference scheduled next week by Ari Juels in Lausanne, CH:
The event
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) with key k operating on inputs from the integers mod z >= n-1 (usually a power of 2 for a symmetric encryption function). Given a CCN c map it to a value c' in mod n arithmetic and generate a random value 0 = r z. We can now encrypt our CCN as the pair r + c' mod n, ENC_k(r).
This will ensure that no statistical test will be able to distinguish a correct choice of the key from an incorrect one.
This is useless, however, for data like english text or names which don't have an easily describable distribution. The construction above relied on our ability to select an information theoretic optimal compression function for CCNs, i.e., one which bijectively maps the message into a uniform distribution on the integers mod n for some n. This is impossible for things like proper names or english text.
If you liked this thought maybe you would find my blog nice too:
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.
Be wary of any facts that confirm your opinion.
About time something like this started to appear .. ..
I think that's the point...it blends authentication and encryption into the same synergistic entity. You mess with the blob, and it dynamically reconfigures itself against you.
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.
OK, that's a good idea.
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.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
That's exactly what drags down the process. You'll need to go through each of the passwords for every brute force attempt.
Also, if that password is banned, that won't work at all. Which it should be anyways.
... 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 data.
The way to work it is to use procedural generation of some type, It should be easy to generate a random looking but believable indevidual files or directory structure (and fill it with plausible files related to the folder names *i.e. avi,mov,mpg in video folder and doc,xls,xdoc etc... in Documents folder.) You could go as far as to generate appropriate file herders and meta data to fool some automated checking.
With procedural generation the same false password would generate the same false data every time so it is harder to differentiate between bogus and actual data.
Laters Sol "Have you found the secrets of the universe? Asked Zebade "I'm sure I left them here somewhere"
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.
Someone had to do it.
Well sort of... but I don't think it's that simple even in concept.
If the real password returns a properly formatted and valid number, expiration date, validation code, name on card, then running a bad password through the same algorithm would always return invalid information... unless you knew the bad password in advance. That means one would have to already brute force the system in advance to know what bad passwords return bad information and adjust accordingly.
if 1234 returns say 4000 0000 0000 0002 (which passes Mod10), great, but you don't know that if using say AES until you actually do it. Unless you have actually broken AES (or whatever) to the point that you can, in advance predict the results an unknown password will return or know a backdoor password. For the former, good luck. For the later, well, there is no 'deception' issue in the first place.
So, as the bad guy, to figure out if you are getting bogus data, as soon as you get an invalid format in any record, in any field, bad guy knows they have the wrong password.
For a good guy, you'd have to come up with a plan to put 'valid looking' data with no invalids or duplicates into the faked dataset and you would have to be able to do this on whatever level the encryption was done at (field, record, table, database, file). The farther you extrapolate out, the more obvious a bad key becomes.
That anticipation seems much harder for the good guy than the bad guy in terms of both programmatic difficulty and computational complexity. On the other hand, only the brute force step is computationally hard for the bad guy and they are doing that already. This seems like a bad idea - high additional cost for the defender without any real cost to the attacker.
All of this so the defender can continue to add more armor to the front door while the attacker sneaks through the window?
Ericsson R520 from the pre-Sony period. I had one too, it was an awesome phone!
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.
www.wavefront-av.com