3
$\begingroup$

For instance say you encrypt text using the one time pad and you end up with some scrambled text that appears illegible. If you reused the key for multiple times for enough text, someone could potentially crack the message using something like crib-dragging. The hacker tries and tries until eventually comes up with a message that has meaning and is no longer scrambled.

However say you use the one time pad technique to encrypt numeric values like dates, time, or just some numbers within a range like say numbers from 00000 - 10000 AND reuse the same key over and over.

For example in the case of dates like a month you would create a key that consists of a random number between 1 and 12, so that when you add the key value to actual month value and mod by 12 (and add 1) you end with a real month value different from the initial. Then you use the same method (different range of values) with the days, or years, always ensuring you end up with a real date value in the end.

First is it even possible for someone to recognize that the result was encrypted? The values all appear to be legitimate, real, non-scrambled values, just as the originals were (only displaced in time)

If for some reason they figured out that the numeric values were encrypted, would they even be able to decrypt them to their original values? How would they know that their efforts are resulting in the correct original value?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

Could someone even recognize that the values are encrypted? Well, maybe, maybe not.

You're correct that the values would all appear to be valid dates (this is known as format-preserving encryption, by the way), so they would not look obviously encrypted, the way, say, a random hex string would. If someone just saw a small number of such dates, with no context to let them guess whether they're plausible or not, they might not notice anything amiss.

Then again, in the real world, your data is never just a bunch of random dates. Rather, the dates will be dates of something, and might be associated with other data (names, descriptions, etc.) that could reveal any manipulation under close inspection.

We don't really know what your dates might be about, so let's just make a random guess and say that they're people's birthdays. Well, guess what? Birthdays are not uniformly distributed. Some months see noticeably more births than others (for example, there's a notable peak in births in September, about 9 months after the Christmas holiday season), and there are also significant weekly trends (presumably because C-sections and induced labor are not usually scheduled for weekends) and sharp peaks and troughs around specific holidays (presumably for similar reasons).

A suspicious person could examine your birthday data and see if it matches these expected patterns. If it does not, they might suspect that it has been encrypted, or otherwise tampered with.

OK, so somebody suspects that your data has been encrypted. (Or maybe they just know that it is; it's generally safest to assume that they do.) How would they go about breaking the encryption? Well, they'd likely start the same way anyone breaking a simple amateur cipher would — with frequency analysis.

Just looking at the frequence distribution of the dates (assuming there are enough of them) should reveal information about the nature of the encryption; for the simple encryption scheme you describe, the distribution of birthdays by month will look the same as expected, except shifted by some number of months. For this simple cipher, this will also immediately reveal the key.

(A more complex format-preserving cipher would typically yield a frequency distribution that looks a lot closer to uniform than normal data would. This is also easily detectable, although recovering the key may be more — possibly much more — difficult.)

In fact, the methods to use for breaking your cipher are basically the same as one would use to break a simple Caesar cipher. Both are simple additive monoalphabetic substitution ciphers; the only difference is that, in your case, the "alphabet" consists of months rather than of letters.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Say you wanted to preserve the linkage to people and their birthdates. Birthday is a primary key in a database and you have multiple records for one person. You want to preserve that the birthdates are not totally randomized so that birthday of each record for same person come to same value. Does any FPE allow for this? - since you say the result is closer to uniform frequency I'm thinking no. $\endgroup$
    – erotavlas
    Mar 1, 2015 at 18:18
  • 2
    $\begingroup$ Yes, that's exactly what format-preserving encryption does. Basically, an FPE scheme for, say, dates within a year, is a keyed invertible pseudorandom permutation of the set {1, 2, ..., 365} (plus 366 for leap years; of course, in practice, you'd also want to use the year as a "tweak" for the scheme, so it won't be the same permutation each year). Every time you feed in the same unencrypted date, the same encrypted date will come out; it will just tend to flatten out any long-term monthly / weekly trends, since the dates will be shuffled around (pseudo)randomly. $\endgroup$
    – Ilmari Karonen
    Mar 1, 2015 at 18:47
2
$\begingroup$

Yes, the same weaknesses apply. Text on computers is a bunch of numbers; a OTP encrypts a sequence of numbers modulo 2.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I see your point, however I don't see how anyone can know if they are looking at an encrypted value vs a decrypted value if they are dealing with numbers like dates. I think my question has to do with that, but not sure how to rephrase it. $\endgroup$
    – erotavlas
    Mar 1, 2015 at 1:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.