When Pretty Good Privacy Isn't Good Enough 169
st. augustine writes "Worried that the NSA already knows how to crack
PGP? Someone calling themselves Hardened Criminal
Software has a one-time pad package called HardEncrypt that could be the answer to your paranoia. The sci.crypt Snake Oil FAQ teaches us to beware of one-time pad claims, but it looks like Hardened Criminal has done their homework. No bogus bit-stream algorithms or pseudo-random number generators. And it's open-source, so everyone can bang on it and fix any problems.
I'd try it myself, but I'm outside the US, and the
Bernstein decision doesn't apply in New York. :-)"
Close (Score:1)
This code is trash. DO NOT USE IT. (Score:1)
In their case, its trash, there are very very few fast ways of generating such pads, The only convinenent one I can think of is
Using OTP is easy, whats hard is generating the pad and getting it to the other recipient.
can we shoot these people? (Score:1)
some peoples children
software (Score:1)
Anyway, if I had sensitive data I'd toss my fortunes with PGP, which rests on the security of RSA and IDEA, assuming no other protocol failures (which should be flushed out as the code is available for inspection).
It's quite usable actually (Score:1)
I challenge anyone demostrate that this modified scheme is insecure.
There are two main reasons why you can safely eliminate Step 1. Number one, many of the previous posts have successfully demonstrated, beyond any reasonable doubt, the author of HardEncrypt to lack necessary crypto expertise. Number two, even if he'd had that expertise, OTP schemes are not practical anyway. To elaborate, consider the following points:
Are we engaged in a theoretical discourse here, or are we discussing a practical matter? The theoretical aspect of this discussion was closed long time ago. The verdict? Truly random one-time pads provide for unbreakable encryption. Note that all comments made Roblimo about NP-hardness, NP-completeness, or undecidability of the problem are irrelevant, as one of AC's rigthly pointed out. So much for the theoretical foundation.
As a practical matter, who do you think is going to try decrypt your piddly emails? For any organization but NSA and its international counterparts, as well as some major corporations, the task of cryptanalysing your PGP-encrypted mail is well beyond its budget. Now, try to think in terms cost-benefit analysis. For all intents and purposes, if any powerful institution were ever to get really curious about the contents of your emails, it would be much cheaper for them to ask you nicely to surrender the key. I mean, real nicely.
The bottom line is, use PGP and get a copy of Applied Cryptography by Bruce Schneier, if you haven't already done so.
Moderate this up (Score:1)
Question about OTP (Score:1)
this subject.
Suppose the following:
We are interested in encrypting messages, not
whole disk drives. One uses some random source
(/dev/urandom?) to make a CDROM OTP of about 600
MB, which should cover most messages and data
file sizes. Now make a second CDROM containing a
series of random indices. Give by secure (ie
hand) the 2 CD's to the counterpart you will
be exchanging messages. Now encrypt messages
using the OTP, but starting at a different point
in the pad as determined from the random indices
on the second CD. Does this message allow you
to continue to use the same 'OTP' for a very
long time without compromising the use once
principle? (This assumes that you can store
the CD's securely).
Thanks
LB
Re:Why OTP is proven uncrackable, in laymans terms (Score:2)
The problem with most "uncrackable" schemes is that they do not dedicate the same resources to key management as they do to theoretical power. Key management is *THE* hard problem in cryptographic systems, and the #1 way to break a system. In practice, something like BlowFish with a 128-bit (or if you're paranoid, 256-bit) key is pretty much unbreakable today, and public key encryption methods are used to do the "hard part" (key management to exchange keys for the "real" encryption method), thus reducing the possibility of it being broken by the expedient of reducing the amount of crypto-text available to be attacked.
Of course, there's always the possibility that some quantum leap in mathematical knowledge will make asymetrical (public key) algorithms unsafe. But symmetric algorithms like BlowFish do not share that quality, and it is a LOT easier to distribute keys for BlowFish than to distribute keys for One Time Pads (said keys which must be the same length as the text to be encrypted/decrypted).
-E
Doesn't use real one-time pad (Score:1)
The latter approach should work pretty well with an audio source (a sound card is used by the programs describe). Audio is usually highly non-random. It depends on what is connected to the audio board. If it is environmental noise, it will probably have certain frequencies emphasized. If it is music, it is already highly structured (except, perhaps, for certain modern rock "music" which seems to me to be almost flat spectrum
Given that the authors claim it is unbreakable, I would immediately suspect that they are cryptographic novices, and thus be suspicious of the details of their algorithms in addition to their poor choice of randomness.
If they had used a semirandom source (like audio or key click timings or something), and THEN used a solid cypher to encrypt it to produce the one-time key, I would be much happier.
The Value of OTP (Score:1)
After an initial secure communication of random bytes, you can send the same amount of data over insecure communication routes in absolutely perfect security.
Think of it; if you sent a CD-Rs of random noise to a friend, you could probably email securely with him for the rest of your life. Nobody could ever crack it, no matter how many billions of dollars worth of computer equipment, no matter how much computers improve, no matter how many millenia they spend on it. If you both deleted the used key data after communicating, and he deleted the message after reading it, nobody could ever know what you told him, even if your computers were seized.
Other reversible encryption schemes merely make it hard to decrypt a message. A large government agency with sufficient resources might do it, or a distributed effort, or a new computing technology might make it cheap and simple. If you encrypt and communicate something that can be damaging to you even 20 years in the future, it will hang over your head like the sword of Damocles for the rest of your life, unless you used OTP.
Any reversible data encryption requires that you use an inherently secure communication channel to send a key to the recipient before you can use insecure channels to securely communicate with him. It's just that in this case the key is large and can get used up. Since the only really inherently secure communication channel is handing someone a disk with the data, why bother with a short key? Disks are cheap, give him a few gigabytes of OTP and be perfectly secure.
Re:Why people don't use one time pads (Score:1)
"j=`K~8v]-2.D:&.6*i$_kQ\?,|)dE" by any chance?
No? Ok... must be a bug in my algorithm...
Their math is wrong. (Score:1)
So, given a large number N, if you know that N has two factors, you can find them by trying to divide N by every number up to N/2. You'll eventually find one of N's two factors this way, and after dividing, you'll have found the other as well. But, there's nothing to say that you won't have to try all possible factors, and there are N/2 of them...
First: You only have to check to sqrt(N), not N/2.
Second: You only have to check the primes up to sqrt(N), not every number.
Third: If the original numbers aren't really prime (say they are only good prime canditates), you don't even have to check all the primes up to sqrt(N).
While this may still be a lot of numbers, it's no N/2.
Re:you need a completely *random* key (Score:2)
Re:Their math is wrong. (Score:1)
in fact, it's less than
1.22506 * sqrt(N) / ln (sqrt(N))
Quantum Computing algorithm exists (Score:1)
Using von-neumann computing, this is true. However, there is a quantum computing algorithm to factor large numbers (you take a quantum superposition of all possible numbers, raise a test integer to that power modulo the number you want to factor, do a fast fourier transform on the result, and add one to the periodicity that jumps out of the noise. There's a good chance that you have a factor, and if not, you can try again.). I believe this algorithm has actually been run on an avagadro sample of quantum computers (otherwise known as molecules in an NMR machine) to factor the number 6. Of course, even if QC obeys Moore's law starting now (and I suspect that QC's doubling constant will be longer than 18 months), there are still a good 20 years or so before it gets to the point of factoring 4096-bit keys, and you can't distribute quantum computations to hurry that up any.
Anyway, the eventual number of atoms needed is theoretically 1 per bit in your computer. The algorithm requires three full-width registers, and any reasonable implementation of QC will take at least triple redundancy and error correction, so that's 3*3*4096=36864 atoms. I would be happy to provide this quantity to anyone who asks.
Re:you need a completely *random* key (Score:1)
The output of /dev/random is 8 bits. (0-255) When you take the mod 95, you get results like this:
-------------------------------
0-94 => 0-94
95-189 => 0-94
190-255 => 0-64
Aag... HTML is no good for aligning things... without <TABLE>s!!!!
This is very bad. Note that the rage from 0-64 is represented 50% more than 65-94! This will seriously distrupt the randomness of your data. In fact, I'm quite surprised your SD was only 0.1, though I didn't do the math myself. At any rate, the correct way to produce values from 0 to 94 from /dev/random would be to %128 (or &127) to cleanly extract 7 bits, and discard values above 94. Then your output would hold up in the histogram.
If you do try this, please let me know at the above email address. I hope I can restore your faith in /dev/random, as it actually is quite good.
Of course, the problem with this is... (Score:2)
Re:node (Score:1)
doh! (Score:1)
don't i feel stupid
Re:Hard Cryptography & distribution (Score:2)
-E
Seems useless (Score:1)
Use PGP to encrypt the random data for your one time pad? According to them, all one would need to do is crack the PGP encryped data to retrieve your padding material. If they couldn't break the PGP... then why are you using this? If they can break the PGP... then they have access to your padding info, and can decrypt all the rest of your communications.
I guess you could send email to everyone and have them send their snailmail addresses so you could send them a custom burned CD... but then, someone who was monitoring your email would know this and therefore intercept the CD's, make copies for themselves and then forward them along to their intended recipients...
I just can't see how this is feasible, unless you use public-key crypto to exchange pad or keys...
Re:Zooko says: DO NOT USE THIS PROGRAM (Score:2)
In other words, security by obscurity does not work in reality, so you might as well use well-tested algorithms that are provably secure (well, secure at today's state-of-the-art anyhow, I make no promises for fifty years from now!). Design of crypto algorithms is HARD. It's very easy to make mistakes. So it's best to use algorithms that are well-known and that have been extensively analyzed, because even experts make mistakes (hmm, was it RC4 that had the weak keys?).
-E
Why people don't use one time pads (Score:2)
Yes, OTP's are completely invulnerable when used correctly. This is similar to saying Micros~1 software doesn't crash when it doesn't come across any bugs.
The essence of OTP is almost trivially simple: generate a large random file, distribute it securely to the receiver of the file, then XOR it with the message. The receiver XOR's it back, and voila, the message!
Of course, the trick here is securely conveying the random file to your communications partner. This is almost as hard as getting a secret message across. You can't email it, or even send it encrypted, because that reduces the security to the weakest link. Thus, all OTP gives you is a form of time-arbitrage. If you can do a secure transmission at time A, that gives you a free secure transmission at later time B.
Then you have to worry about only using the pad once. If you use it twice, your message is totally toast. During WWII, a lot of traffic was gathered this way.
Finally, you need to worry about the keying material. If it's recovered (on either side), your messages are also toast. Since you need to store the key between the time of key exchange and the time of message exchange, it's a pretty ripe target for somebody to snatch off your hard drive. And forget about storing it encrypted - the same weakest link problem.
So this is why people don't use OTP's. You get perfect theoretical security, but in practice keeping track of the keying material is a bitch.
Finally, if you really want to do OTP, I recommend grabbing some
Happy ciphering!
Yawn. Paranoia sucks (Score:2)
With symmetrical algorithms 256 bits gets you unbreakable for the next 50 years or so (depends on the algorithm, of course, but I'm thinking a good one like one of the AES finalists). With assymetrical (public key) encryption there is a bit of doubt there -- the public key does include information that could be used to derive the private key, but it would require a quantum leap in our ability to solve certain hard mathematical problems.
In any event, if I'm a national government and I want to ruin your life all I have to do is flash my FBI batch at your local sheriff's office, tell him that you are a drug trafficer, and then said sheriff can immediately burst into your home and sieze your property and all bank accounts. You then must prove that your possessions were not bought with drug money in order to get them back, but how are you going to do that without money to hire a lawyer (because they siezed your bank accounts, remember?). And how are you going to do that without a job, because said deputies burst into your employer's office, told them you were a drug dealer, and seized your computer at work, thus resulting in you being fired? We already have a police state, it just tries to be polite about it except when dealing with what the majority thinks is the "scum of society".
-E
Huh? (Score:2)
Or am I wrong? There's a first time for everything.
A note on OTP key generation (Score:1)
There are two basic acceptable ways to get gigabytes of useable OTP key: use theoretically sound true random numbers (the better way), or use a totally personal source of more-or-less random numbers (more or less a type of security through obscurity, with the same major pitfalls that you might screw it up or others who worked on it might betray you).
The first and best method is better covered by more knowledgable people. I'm not entirely sure it exists. There is a theory for generating psuedo-randoms, but that's totally different. The only way to really follow this may be to have a hardware device that generates quantum mechanical noise.
The important thing in using the second method is not to follow any sort of standard method. Pick a random mpeg file, use the numbers as keys in a pseudo-random generator (one key to one pseudo-random; yes, it's predictable and reversible, but most manipulations will be, the important thing is that the data they work on won't be), then use those numbers as offsets to pick out bytes of pi. Roll dice to choose a number to xor an audio file by, then take counts of occurances of each byte value and then partially normalize them to a dice-determined extent by pseudo-randomly (with a dice-generated key) changing the common ones to rare ones. Actually, don't do those things, because if they seem obvious others are probably doing it too. Change approaches each time you decide to whip up a new batch of key. The important thing here is that your approach is original and not standard, so the people who try to make educated guesses based on statistical trends won't have any statistical trends to work from. If they don't _know_ that there are statistical trends, they can't just assume it and get something useful. Of course, these assertions are unprovable; but, IMHO, that a sequence of numbers is truly random is never proven, merely plausible.
Re:Why people don't use one time pads (Score:5)
"now here is the second string"
(i guessed at the last part, since they were of unequal length).
it took me about 15 minutes to hack together some perl code to help me do it--easier than doing it by hand.
and i've never done this before.
it's amazingly simple, actually. you have two plaintexts, T1 and T2, a key, K, and two ciphertexts, C1 and C2. you're trying to find T1 and T2. you don't know (and don't really care about) K, and you know C1 and C2.
so you have:
C1= T1 XOR K
C2= T2 XOR K
now the problem is, we don't know K. so we think about things briefly and suddenly realize:
C1 XOR C2 = T1 XOR T2
which takes the key entirely out of things, making it simply a case of finding two plaintexts XORed together. which is a piece of cake (especially for simple plaintexts like what you provided).
specifically, i took C1 XOR C2 (call it R) and went through it sequentially, XORing the string ' the ' (with the spaces).
this gave me two hits:
07.......e is
11........... firs
figuring it was likely that this string occurred in both T1 and T2, and unlikely that it occurred twice in any one string in such close proximity, i figured these were each parts of T1 and T2, respectively.
then i XORed ' first ' with R in the right spot, and it gave me ' the se'. i tried all the letters a-z after the 'se' which formed part of a word, i.e. not 'sez' or 'sek' or 'sej'.
with some experimentation, part of the message became clear, and it was easy to extrapolate to get the rest.
with some effort, a program could be written to throw a dictionary at it (in nearly any language, and any character encoding or file format) and see what develops. pretty straightforward stuff.
does that answer your question?
--plambert
Not a storage encryption method. (Score:1)
Re:Hard Cryptography & distribution (Score:1)
Re:Why people don't use one time pads (Score:2)
The problem with re-use is that it provides the cracker with a way to verify a guess.
The big problem with cracking a OTP is that there exist many possable keys. Each key will produce a plaintext. The cracker can eliminate nonsense plaintexts, but each sensible plaintext is just as likely as any other. That is, "We attack at 0100" and "We attack at 2153" and "Let's all go home" are all equally likely. If there is a second text known to be encrypted with the same key, only one of the three test keys above will be likely to result in a sensible plaintext for the other message. In short, the solution space shrinks dramatically with each additional use, and the certainty for the cracker increases.
Note, the above example is over simplified. In fact, there are many more possable solutions, and even with two uses, there could still be several possable keys. However, the general ideas are all there.
Re:The Value of OTP(Little/none) (Score:1)
Hard? I think the word you mean to use is intractable, which is to say possible but unlikely in a short amount of time. For example, while it is possible to crack an RSA encrypted message, it is unlikely that it could be done without a tremendous amount of time + resources (assuming a large key).
Also, your thoughts on security "even if your computers were seized" is wrong. If you or your recipient had that block of "random data" on their computer (or cd or whatever), it would be not too intensive to crack the encrypted messages still stored on either computer. OTP encryption is nearly useless as far as digital data is concerned.
It's unlikely that the feds have "cracked" PGP (which is really just a key protocal. It might be more accurate to say either/or RSA Diffie-Hellman). To do so would require either very unlikely mathematical advances (easy to factor large numbers, solve knapsack/travelling-salesman problem, etc) or absolutely ridiculous amounts of computer equipment (1000X distributed.net in a basement somewhere). In other words, pretty unlikely.
This is what happens when people confuse mathematic/scientific terms for their normal English usages. Unlikely really does mean not very likely, but in the sense of intractable rather than "probably not."
--Andrew Grossman
grossdog@dartmouth.edu
Re:Why people don't use one time pads (Score:1)
As soon as you use the pad a second time it's no longer a "One-Time" Pad...
What you describe is basically how a stream cipher works, except that K is supposed to be continuously changing based on an initial seed from the key. If the stream doesn't change then yes it's totally insecure.
Which isn't to say that's stopped people from using such things. Examples of such encryption are the MS SQL 7 login packet and the MS Windows
Re:NSA and quantum computers (Score:1)
Personally, I think the most insidious influence reducing peoples inclination to secure their own privacy is glib cynicism. The tools are there if it matters but if you don't want to bother you can claim, "they could use their superior technology to beat anything I'd try"
Re:As I Understand It (Score:1)
It comes down to your own personal security criteria, but I'd rather trust a problem that bright people have worked on for centuries (factorization) than one which involves newer (and thus less well-understood) math. That's my personal take.
When it's safe to use the same key twice (Score:1)
It's safe to use the same key many times with a secure block cipher, though you need to worry about chaining modes to avoid providing the same input block twice. It's safe to use the same public key for years with the same caveat.
No, the real take-home message, I'm afraid, is that designing secure cryptosystems is really difficult and you should know a lot about crypto before you field one. Your best bet is still to use PGP.
--
DO NOT USE: Does not unbias stream (Score:1)
Explanation:
The One Time Pad is secure, if impractical, only if the key consists of truly random bits. If the key is a sound file, an image, a set of "random" keystrokes etc it will not be truly random. It will have statistical properties , or "bias", that will reveal part or all of your message. For example sound values tend to follow periodic patterns.
It is true that the input stream may contain enough randomness, or "entropy", to encrypt your message. But generally you have to record a large amount of data containing randomness, say audio, and run it through an algorithm that generates a much smaller, unbiased random stream.
There are some ingenious algorithms to do this removal of bias if the sources are entirely random but biased, eg. weighted coins. It is not possible to write a general purpose utility since you do not know how random your source is, and therefore how many source bits to consume per key bit. The program in question appears to mix the source bits in an ad-hoc way that seems, well, crap.
Personally, when I want some random bits I run md5sum, type a few pages of "random" keystrokes and press ^D. Out come 16 bytes that I can be pretty confident are random.
Pavlos
Re:Some thoughts on encryption (Score:1)
/.
Re:Why people don't use one time pads (Score:1)
Well, that's hardly a surprise, since what plambert was demonstrating was how easy it is to break the encryption if you re-use your one-time pad.
So drop the header (Score:1)
Cheers,
Ben
Re:As I Understand It (Score:1)
PGP and friends do rely on hard mathematical problems. Factoring large numbers is a problem that has been studied for hundred of years. Algorithm improvements *have* taken place. Factoring a 512-bit number used to be unthinkable; now it is (just barely) possible. 4096-bit numbers are many many orders of magnitude more difficult. So it is possible to extrapolate from the current rate of algorithm improvement and an estimate on how far ahead of "the rest of us" the NSA is to get an idea of how secure PGP is. Give the NSA ten years advance, and 4096 bit keys are still safe for a couple of decades (at least!).
And, no, it is *extremely* unlikely the NSA would *ever* be able to factor 4096-bit numbers in *seconds*. Admittedly no one's been able to prove a lower time bound on the integer factorization method, but this problem *has* been studied for centuries. Quantum computing *could* change the paradigm, but the amount of precision one needs for 4096 bits is quite daunting.
And the "near primes" that PGP uses have an astronomically small chance of being non-prime. Basically, the parameters of the algorithm are chosen so that it's about as likely that a person can randomly guess the symmetric key. And generally if the number is non-prime, PGP encryption just plain won't work. Which means that *no one* is able to decrypt your messages (not even you) --- a situation that would be quite obvious if by some miracle it occurred.
Please read
http://www-users.informatik.rwth-aachen.de/~sen
for more information.
NSA *has* broken OTP before (Score:1)
OTP is provably secure, if used properly. Use a pad twice and it's not just insecure, but it's almost completely insecure.. Conventional block ciphers and stream ciphers suffer from weaknesses but they are usually only partial weaknesses.
If you've got important data, a good source of random bits, and the discipline to use it, OTP is unbeatable. For most of us something like PGP is plenty, (or GPG, when are they going to plug RSA in? on my birthday next year?)
In some circles, the belief is that the outside world has caught up with NSA technology, I've heard more than one well known cryptographer make that statement, it's really just an issue of funding. NSA can build bigger and faster computers but there is a level where that doesn't add up to much. RSA (800+bit) and 3DES are most likely secure beyond your lifetime..
I'm not sure that's right (Score:1)
After an initial secure communication of random bytes, you can send the same amount of data over insecure communication routes in absolutely perfect security.
I don't think thats correct. As I understand OTP if you re-use the key the complete security is broken. As the randomness is gome. In order to use an OTP and securely communicate with a friend you must exchange a new key before each transmission. Thus the steps would be more like
Nobody could ever crack it, no matter how many billions of dollars worth of computer equipment, no matter how much computers improve, no matter how many millenia they spend on it.
Nope. no one could crack the first one, but after that it would be possible with a difficulty depending upon how the data and key were combined.
Re:Huh? (Score:2)
Why? (Score:1)
There are more of us, we have less obstructions in the way we communicate (why work for the military when everything you do is watched and your every movement under suspicion, and who you are allowed to converse with strictly limited), and our stucture (or lack of) allows ideas to propagate faster.
We have outpaced the poor fools in the NSA and others and will overtake them soon, if we have not already done so. Things like 'milspec' slow down their processes enormously and they are losing their edge. And yeah, they are shit scared. Witness all the legislation attempting to censor the net and more.
PGP and other public key systems are very secure. The factorisation problem has not been solved. Shortcuts may have been found, but increased key lengths will easily keep up with this.
-- Reverend Vryl
Thanks for clearing that up (Score:1)
anonymous@wacko.org (Score:1)
Ted Kaszinski and Timothy McVeigh finale gawt thar emayl uhcowntz at duh big howse...
Re:As I Understand It (Score:1)
Well, it's more that the 'near primes' that PGP uses have an astronomically small chance of having 'small' factors. The number may or may not be prime, but it isn't obviously unprime. (It's not even for instance.)
And generally if the number is non-prime, PGP encryption just plain won't work.
Not quite. A prime number is no different from a non-prime except that it has less factors. PGP can't tell if a given number is prime except by trying to factor it, otherwise it'd simply test all the numbers it generated and this whole 'near prime' thing wouldn't even be talked about.
We can't tell how far ahead of the rest of the world the NSA is. Most of their mathmeticians aren't actually working 9-5 at cracking codes, they're engaged in general research, so they've got many more people working at advancing the field than anyone else. Other mathmeticians have to pay the bills and then work on crypto in their offtime. Also, it's hard to look at the general level of math knowledge and tell how far ahead someone is. We do know that the NSA advised (IBM?) to change DES for a then-unknown reason which was only discovered years later. But, do we know when this was discovered then by the NSA? Perhaps they worked it out years earlier. But perhaps this was discovered mainly by someone curious as to why the S-Box design was dictated by the NSA. If unguided, perhaps it would have been fifty years before that was discovered.
We don't really know what state of the art is for the NSA because they tend not to publish. They also hire a lot of civilian mathmeticians without saying precisely why. Are they perhaps taking the one who seem closest to actually figuring something important out and leaving the non-crypto oriented and the less bright (and the contientous objectors who won't do government work.) to advance common knowledge?
Perhaps prime-based crypto is better to use than one of the newer non-prime algorithms simply because of the ammount of peer review, but we don't know if we're 2% or 95% of the way to being able to trivially factor large numbers, trying to guess where the NSA is seems even harder.
um... (Score:1)
Well, if you're outside the US then US law can't touch you anyway, so you may as well just download it and look at it.
Right. US law just nails the software authors' asses to the wall instead. Remember what happend to Phil Zimmerman...
---
Re:OTP is an NP-hard problem? (Score:1)
I wonder if it is a troll?
S
Re:node (Score:1)
Have fun . . .
-- Reverend Vryl
I disagree (Score:1)
I care about movies and The Who, but I think some Floyd plugs would have been nice (R. Waters is on tour right now.).
I did not think that this article was that bad. The code needs some revision and more planning, but OTP is a encryption possibility. It seems good to have as many options as possible.
I don't understand why you'd visit a site if you did not care for the subject matter.
Has anyone else noticed that slashdot's banner adds appear a good thirty seconds to a minute before the page appears on win32-ie5 and linux-potato-netscape-461? A conspiracy? I think yes.
node (Score:1)
yeah, yeah . . . preview before submit . . .
It ain't that exciting a link anyway.
-- Reverend Vryl
Re:Some thoughts on encryption (Score:1)
With a little bit of software, you have genuine random numbers.
I don't think OTPs are as impractical as some people say. I can put 1.44 MB of random numbers on a floppy disk and hand deliver it or send it via registered mail to my correspondent. That will encrypt a lot of email. The U.S. Government routinely uses registered mail for classified documents and keying material.
Re:As I Understand It (Score:1)
So : Factorisation element NP = ?
Re:Some thoughts on encryption (Score:1)
There is one industry (and its regulators) that must deal with RNGs on a nearly daily basis: the Gambling (excuse me, "gaming") Industry. The question is, what sort of hardware or software RNGs do they use, and how do the various regulators (e.g. the Electronic Services Division of the Nevada State Gaming Board [state.nv.us]) verify that the RNGs are random enough?
Re:The Value of OTP (Score:1)
OTPs are perfectly fine for long-term, low-bandwidth communication, and you don't have to worry about some new magic black box (like a quantum computer) coming along five years down the road and having all your old messages that someone stored instantly open, or ever having to update your encryption software (your keys, OTOH...).
Imagine having a smart bank card that stored enough OTP key for a year's worth of transactions. Once a year (or time unit X), you'd have to feed it into your presumably secure local branch computer, which wouldn't be too inconvenient. It could be the only long-term (as in credits for the Galactic Republic, though it might become necessary much sooner) solution for verifiable money.
Also, OTP is not "strictly one-to-one," it is like any other symmetric reversible encryption (except, as I said, that the keys are large and are consumed on use, and it is unbreakable). It can be "group-member-to-group", where everyone with the key data can send and receive messages to everyone else. I suppose I'm splitting hairs here.
BTW, I never said it was a good general replacement for public-key encryption, or securing your data in an insecure storage location.
>"OTPs are not useful in general computing. Period. Any attempt to pretend that they are is foolish, and gives a false sense of security."
I don't know how to argue this one, since "general computing" is too fuzzy a term to argue with. One could well argue that encryption in general or 3d cards have no use in "general computing." I agree it's excessively troublesome for the typical user who doesn't care if the FBI or a rival corporation is listening, or if it might be cracked in a few years. I certainly don't see how, when correctly used, it could give anyone a false sense of security, unlike encryption schemes that can be broken by sufficiently motivated groups.
Re:Snake Oil (Score:1)
Reusing OTP's (Score:1)
For example, as another poster suggested you could share a really huge random stream on DVD between two locations. Then as long as you store some indication of the last byte used you can use up the data in small chunks, and when you run out you get a new DVD.
All you'd need would be a wrapper program which called HardEn/Decrypt with the message and an appropriately sized chunk of data from the DVD. This program would keep a record of the current position on the DVD, but the DVD would still hold the keying material and you couldn't do anything without it.
You misread it (Score:1)
So if you share a few gigabytes of random data with a friend, everytime you want to send a message, you chop out an appropriate quantity of noise, use that as the key and never use it again. Of course, you'd have to take care that you and your friend were using the same piece of data for the same message, but that's trivial (prefix to the message the offset into the data table you gave, or something similar).
Indeed, though, they are called One Time Pads for a reason. If you reuse a key, or part of a key, the key (or part) can be cracked.
The point that many people seem to be missing is that you can transfer key data for an arbitrary amount of communication at one time. You don't have to be constantly couriering keys for each individual message. You don't need the message to make the key.
Re:Not a storage encryption method. (Score:2)
The exception, of course, is if you have a secure channel at one point in time for key distribution and to establish a protocol for exchange of data at a later time... just don't run out of OTP key data! And, of course, now both the originator and the recipient of the data must securely store the OTP data
Re:pgp not secure (Score:1)
keys (Score:1)
well, that sounds pretty cool. wonder why no one thought of this before
NCSA? Must be why Mosiac has no encryption... (Score:1)
True (Score:1)
Ben
I doubt they have better algorithms (Score:1)
However on the practical side using routine application of current theory and sufficient money (ie hardware) you can indeed get better results than are publically available. It is a safe bet that various 3 letter agencies have made this investment and can crank through tremendous volumes of material encrypted with legally exportable encryption.
Incidentally anyone with any questions on encryption should wander over to the RSA [rsa.com] folks.
Cheers,
Ben
Re:Zooko says: DO NOT USE THIS PROGRAM (Score:1)
While I trust PGP and SSH, at least for versions in which I can get my hands on the source, I'm interested in knowing why you trust hushmail. It just seems to me that directing mail through a central server is a good way to blow security. Even if hushmail is secure and honest (and I have no reason at this time to doubt either), it just seems to me that this is adding a weak link to the chain that really doesn't need to be there.
Did their homework? (Score:1)
"given a large number N, if you know that N has two factors, you can
find them by trying to divide N by every number up to N/2".
Apparently no math major has reviewed their work (should be "up to [sqrt(N)]",
where [] denotes integer floor function).
Re:Why people don't use one time pads (Score:1)
EJB
Re:The Value of OTP(Little/none) (Score:1)
A short amount of time is a very fuzzy concept. "Intractable problems" from a few years ago are being solved today. Who knows what'll happen in the coming years? Proven mathematical impossibility can be very comforting in the face of unpredictable future developments.
I agree with the idea that some other encryption schemes are good enough, so long as nobody cares about your encrypted data enough to want to hang on to it to decode it even if they can't manage it for years.
Also, your thoughts on security "even if your computers were seized" is wrong. If you or your recipient had that block of "random data" on their computer (or cd or whatever), it would be not too intensive to crack the encrypted messages still stored on either computer. OTP encryption is nearly useless as far as digital data is concerned.
Kindly note that I qualified this statement with "If you both deleted the used key data after communicating, and he deleted the message after reading it". In the case I was referring to, there wouldn't be any "still stored" messages or key data you are talking about them using. Of course, you would have to take inconvenient precautions to prevent this from happening. The exceptional situation you are referring to is analogous to someone bursting into the room while you are editing a message; it is also solvable by similar means: only take messages at pre-arranged times, have your system configured to auto-delete when you aren't there to receive, and have your system configured with a panic-button or deadman switch which you man while receiving to auto-delete if you are interfered with. The alternative is special hardware rigged with self-destruct mechanisms. Of course, now we are talking about some ridiculous extreme spy-vs-spy security; most sane people would be happy with an auto-decode and cleanup on reception and encryption in a less secure fashion for those messages which are being temporarily stored before being read (actually most sane people are happy without encrypting their email...). The point I was making is that once you're done with a message and you've cleaned up after yourself, it's utterly gone, no matter who has recorded the insecure transmission or what they're willing to spend on decoding it.
Re:Zooko says: hushmail rocks (Score:1)
IMO, it's better than SSL secure webmail, but worse than PGP.
Re:Looks OK, but the problem with 1-time pads is.. (Score:1)
2. Yup, you gotta carry the DVD ROM disk to the other endpoint and you gotta have some way to know the other endpoint hasn't been coerced or turned. A problem for spies, but OK for most commercial use. It also gets unwieldy for large groups, especially if the same info has to be securely transmitted to many people. Too hard to keep track of that many key disks. But if your object is to connect two people securely, it's no biggie.
3. A DVD ROM is about 6GB, full rate speech on the telephone network is 64Kbps or: 8KBs, 480KB/min (roughly half a meg, let's say), so that's 30MB/hour, and over 30 hours of speech encoded with one DVD's worth of OTP key. Compress the speech 8:1, and you get 240 hours per disk! You talk that much and people might begin to suspect a conspiracy.
Weigh the problems against the benefits: it's so simple, real time speech encoding and decoding is no problem at all, even for multiple channels. This is where high key length public key falls down: it is too computationally expensive for multi-channel real-time voice. The required hardware is so simple that you can go to great lengths to assure yourself there are no exploitable features in the hardware. Use a DVD RAM and your hardware can be programmed to erase the disk as it is used up to idiot-proof the system. And the code is so small it can be trivially exported in printed form.
Re:Reusing OTP's (Score:2)
That would be fine, I agree... The key distribution problem restricts what you can do with OTPs to a limited set of problems, but if your problem falls within that domain it's acceptable.
However, if you do this, please for gods sake don't use this program! While the encrypt function is trivial (and bad, still, for reasons I briefly explain later), the GenKeyFile as ATROCIOUS . It makes me physically ill to think that anyone would pass that off as an OTP generation function.
The attack on it is trivial, given physical access to the machine. (I.e. it was seized, etc.) Presuming the GenKeyFile program was used, the key file is generated using rand(), seeking through a seed file and generating the bits for the 'true' key file. Even if you wipe the 'true' key file (that gets generated by this program), but keep your initial seed file around (i.e. you're using \winnt\system32\mfc.dll to generate your random bits), here's what your security comes down to:
32 bits of seed (for rand())
n bits of search where 2^n is the number of files in your filesystem (or the next power of two over it).
The assault on this method is as follows:
For each file in the system, iterate over the 32 bits of rand(seed) space, and test the resultant file for known plaintext. (What's that, you believe that they don't know any plaintext in your document? Not true! Headers, average character counts, etc., all are telltales!) With only 32 bits of seed for your rand() function (or 64 if somehow you have an extended rand()), the keyspace is not sufficient to produce truly random output. Thus the number of matches that will generate a pattern that is similar to the expected pattern (text, images, etc., all have non-random recognizable patterns) is very small, and might be zero.
There are four components to this 'encryption package':
If you keep the seed file OR the keyfile around, then this encryption is 100% useless. The seed file can be found, and the rand() function gives you *LESS* protection than DES, and MUCH less than IDEA, 3DES, etc...
Even if you've erased both your keyfile and your seed file, if the attacker can presume that you ever USED GenKeyFile to make your key data, the resultant ciphertext will be encrypted with patterns that are the result of the patterns in the seed file, mixed with the (reasonably well known) patterns of the rand() function. This patterned data can be identified by a sufficiently dedicated attacker, even w/o the original source file. Do not use GenKeyFile!
You're *far* better off using
Seriously, this is snake oil. Well meaning snake oil, but snake oil nonetheless. Presuming a seized computer, and either the use of GenKeyFile at ALL , or the preservation of your used key file, this gives ABSOLUTELY ZERO PROTECTION FROM A COMPETENT ATTACKER.
Cyberfox!
p.s. While the encrypt program is still useful with an OTP generated from a secure source, it SHOULD be repeatedly wiping the used padbits out of the Psuedo-OTP's filespace as it goes, but it's not... Another example of less-than-stellar competency.
Important related note: You don't use an OTP to encrypt to yourself, because you never ever ever want to keep the OTP bits a millisecond longer than it takes to encrypt it initially.
p.p.s I can't say this enough, but I'll try one more time, please, please, please DO NOT USE GENKEYFILE TO BUILD YOUR KEY FILE!
Author doesn't know beans about one time crypto (Score:2)
After you make a key file, you can use it over and over again
and helpfully suggests that
you might want to make a separate key file for each person with whom you want to exchange encrypted files
No no no! You DO NOT re-use one time pads. You DO NOT share one key with multiple people even with "lesser" crypto systems, but ESPECIALLY withone time pads, because that implies re-use.
One time pads are only unbreakable when used just once. Multiple uses leave clues for analysis.
Anyone who knows even a little about crypto knows that the weakest link is managing the keys. That's why PGP's private keys are hidden by that obnoxious pass phrase. If the black bag guys break into your computer and copy your PGP files, they still have to decrypt them because your pass phrase muddles things. With this one time pad, they have the key immediately, no further work required.
This guy seems to imply you should keep your one time key lying aorund the hard disk so you can encrypt and decrypt at will. Good gosh, PGP encrypts the private key with the pass phrase at least. Here you leave your one time key OUT IN THE OPEN, and REUSE it, over and over again. This is NOT secure crypto.
THIS IS LESS SECURE THAN PGP. This is a silly little toy and DOES NOT PROVIDE SECURITY.
He massively understates how easy it is to factor RSA private keys. He says "it is possible", yet he is wrong. Until and unless new algorithms are found, there are not enough atoms in the universe to factor 4096 bit keys before the universe collapses back into the next big bang. Luck does not enter into it. There is only so much theoretical computational power available in the lifetime of the universe; it won't crack even a single key. And if you spread it over multiple keys, then the chances for any single attack drop correspondingly.
--
Great demo! (Score:1)
The take-home message here is that it is generally safe to use the same key a number of different times with a conventional secret-key system, but not safe at all with a one time pad.
Re:Not a storage encryption method. (Score:1)
Pragmatic Nearly-OTP systems are live and well (Score:1)
The transformation functions should be parametrized by N*(1:M) keysets where M is very large: for example, if M is the number of bytes on a publicly-available music or games CD and N is the number of CDs you decide to use, then the distribution problem boils down to sending N names of CDs from Bob to Alice, plus the name or number of a transformation function if you choose to vary that as well.
That's a trivial amount to distribute securely, even over a low-bandwidth covert channel, and the largeness of such an M creates a combinatorial explosion that would give the biggest of cracking computers something to think about for a long time. Consider the number of different CDs in the world (and MP3s!) and the computational task of combining them even for a trivial linear correlation, then consider that N is unknown to the cracker, and then consider that arbitrary transformations can be applied to the keysets first to render linear correlation fruitless: the problem becomes utterly infeasible to solve by brute force, not because of strong cryptographic properties but because the universe of key-seeded transformations on the underlying pad is limited only by the imagination.
So, if you're willing to be pragmatic about it, (N-)OTPs are live and well despite a theoretical key distribution problem --- ie. the ability to dereference from a name to a keyset means that the CD publishers perform the bandwidth-intensive distribution for you.
It's all about Entropy (Score:1)
The audio file they use to generate the key-file will be converted into a a key-file of about the same size. (They remove the static headers.) As they say, audio files are going to contains noise and be difficult to reproduce exactly. However, an audio file is nowhere near being completely random. If it were completely random it would be impossible to compress, for example. If the best possible lossless audio-compression algorithms could compress the audio-file down to, say, 1/64 size, then obviously it would be enought for the attacker to guess the compressed file, expand it and generate your key.
This is mostly of academic interest, though, since guessing 1/64 of a 128KB audio file is completely out of the question. But it does show that their claims are not completely true.
A better description of the system would be a Pseudo-OTP, using a pseudo-random number generator with a very large initial seed. This could still be a secure system, assuming the PRNG they use were any good.
Looking at the source code (go OSS, go!) it doesn't look particularly effective. It "randomly" picks bytes from the seed file to output. It then xor's it with a "random" byte. These "random" bytes are from the C rand() function. This is done 5000 times, the buffer written to disk and rand() re-seeded from a key-file byte.
I'd say that the GenKeyFile program doesn't do anything useful to the seed file. Here is how I would recover a good portion of the plaintext:
Since the seed for rand() is small, we can loop through all the possible guesses without any trouble. Step 4 will return bytes of the form C ^ r where C is the cipher-text and r is the bytes we are using from rand(). C will be of the form P ^ S ^ r' where P is the plaintext, S is a byte from the seed-file and r' is a byte from rand() used in the encryption. If we guessed the seed for rand() correctly we'll have output 5000 bytes of the form P ^ S ^ r' ^ r = P ^ S.
In other words, it is easy to completely strip away the pseudo-random mixing. The distribution of bytes in the seed file (assuming it is sound) will be far from uniform. In fact, it will probably contain a lot of 0's, especially if it is your own voice, as they recommend for beginning users. Uncompressed audio tends to be sampled at 16 bits, and for large parts it will have the high byte zero (low volume). In other places it will have either the low byte small (really low volume) or the high byte small (fairly low volume). All in all, a lot of the S values can be expected to be zero. This menas that we can:
This is where you would have to start doing mildly tricky stuff like looking at the actual probability distributions involved, etc.
Short version: Don't use this stuff.
Slightly longer version: This looks OK, if you just use a good seed file. A compressed audio file would be a start, WAV files are completely out of the question. Actually, you should just dump as many bytes as ou need from /dev/random and make that your key-file. Now we just have the usual unsuitability of the OTP to practically anything to contend with.
Got one thing right. (Score:1)
I was really afraid I would see them recycling the key if it wasn't long enough. Fortunately this code snippet shows they at least got that right:
if(numKeyBytesRead < numInBytesRead) { // check for a small key
printf("\nERROR: keyfile must be at least as large as input file.\n");
printf("Output file is incomplete\n");
}
Of course they don't bother with how the sender/receiver should exchange the key file in a secure fashion.
Looks OK, but the problem with 1-time pads is... (Score:2)
...that they're almost completely useless for most tasks.
A full discussion of one-time pads can be found in Applied Cryptography, 2nd ed, by Bruce Schneier (page 15).
One time pads have several problems that make them useless for anything but locking individual files (and even then, it's quite a pain).
Onetime pads, while cool in a theoretical sense, are useless to virtually everyone with the exception of diplomats. For diplomatic use, they can solve the key storage/distribution problem via CDROMs/Digital tapes transport via diplomatic courier bags. Everyone else is screwed. Even the millitary doesn't generally use onetime pads because of the key distribution problem.
Stick to high-keylength public key or symetric cyphers. They're far more useful, and the likelihood of them being broken by even the likes of the NSA is not good.
-Erik
Some thoughts on encryption (Score:2)
The trick is that you have to come up with a process that generates a random bit-stream. The classic example is 2 Geiger counters side by side. (Throw away results from both that arrive shortly after the either fires. There is a slight latency and this gets you independence.) There are variations of this that can easily be set up in silicon much more economically.
But, you say, this gives you a biased stream? Yes, but an independent, random one. The next step is to take the output in pairs, drop the pairs that are the same, and then take the first bit. This gives you an independent unbiased bit stream. Well there is a miniscule bias, however it is slight enough that it would not be reliably detectable if the machine operated for several billion years. I consider that acceptable.
This does throw away about 3/4 of the data. Some of this can be recovered and used, after all your "accept, don't accept" is a bit-stream, and so is the set of values from the pairs that agreed. Both are more heavily biased than your original, but a few layers of this will get a lot more information extracted.
Unfortunately no such random number generator done in hardware is widely deployed. If it were then encryption would be a lot better than it is today but...
My other thought was an encryption algorithm that requires lots of random data, but is better than a OTP for transmitting a stream. First of all a common but bad algorithm is to XOR a bit stream with a random block of data, but reuse the block. While a OTP is unbreakable this variation is easy to break. Just XOR the output with itself shifted over, and when you hit the length of the stream you will get a large spike in certain characters. That tells you the length and a good cryptographer can work quickly from there.
A slight variation on this would be to have 2 random blocks of data, of different length, and XOR both of them against the original. This is still breakable but it is harder since each block hides the other.
My idea is to have the 2 random blocks of data, but have the transmitted stream of data be randomly sending the message and replacements for each block. This means that the random blocks of data are each hiding the other and the transmitted changes to the key, while they are themselves getting replaced.
I suspect that if you devote enough of your bitstream to the replacement of the bitstream that this variation is very secure. Unfortunately it needs a large supply of really random bits, and that is not easy to come by...
Regards,
Ben
PS One supply of pretty random data is as follows. Compress some large binaries as much as you can, and then sample the result. A well-compressed file looks a lot like random data...
As I Understand It (Score:1)
-- Reverend Vryl
Not a one time pad :-( (Score:1)
Why This Program Isn't Very Secure
Audio data is not very random. It contains lots of patterns. Record a sound file (or save an MP3 as a WAV) and look at the file. Some bytes show up more frequently than others. So at a minimum, an attacker can probably perform some messy statistics and discover some general things about your file--which byte values show up more often than others, for example.
Some Good Things About This Program
This program uses a poor encryption algorithm but a very large key. So even if parts of the file are decrypted, other parts will always be garbage. Most attacks on this progam will give probabilities, not definite results.
How to Fix It
Remove the one-time-pad entirely. Replace it a quality block cypher (this allows you to use the same key more than once, which you can't ever do with a one-time pad). Use your audio file (or other file) to generate a large key. Decide on a way to use your enormous key effectively.
How to Lean More
Read Applied Cryptography. [counterpane.com] Modern cryptography is very, very good, and there's no reason to fool around with one-time-pads and pseudo-random number generators.
Not uncrackable, but close (Score:1)
Theoretically, a OTP is uncrackable. No amount of computing power can crack, not matter how long you try.
Convinience is the point (Score:1)
Re:The Value of OTP (Score:1)
I don't mean to endorse the general use of OTP for routine emails and such (I'll admit it sounded like I did in my original post; I cut out as obvious a part I typed about the needless expense and the typically limited need for security, but forgot to change the "it's perfectly secure! and not that expensive" contrast piece at the end). I agree that it is a waste of effort for most people.
The point was that OTP is the only reversible general encryption scheme that is absolutely unbreakable when correctly done (dumb codes are also unbreakable, and potentially unrecognizable as well, but not general). Not expensive to break, not impossible to break in a human lifetime using modern computers, but absolutely unbreakable. It is also practical even for individuals with typical cheap home computers, certainly a needless expense for most, but a relatively small one, and still feasible.
I certainly believe OTP will become more important in the future, as exotic computing technologies emerge and change the rules about what is intractable. They may well become the foundation of commerce as everything becomes copyable and all material products are commoditized, leaving no form of portable and quantifiable wealth.
Your suggestion that investigators can read data from your hard drive after you've deleted them, is very interesting. I hadn't really thought of that, but the principle is still true, if you really clean up after yourself properly (which is a lot more bother than I thought, though still feasible).
Here's a good article on the problems and how to try to get around them (it's more complicated than I first thought, and gives interesting insights into harddrive function if you have as naive a view of the encoding on such devices as I did; very interesting reading indeed):
http://www.cs.auckland.ac.nz/~pgut001/secure_de
not utterly useless (Score:1)
It's not utterly useless, just not very useful for the typical person at this point in time. Diplomats, spies, business executives, politicians, criminals, revolutionaries, and terrorists could find it invaluable (not necessarily a good thing for humanity in general...) and I think that in the long term it could become the only useful form of encryption and possible the base of all commerce.
NSA vs NCSA (Score:1)
NCSA is the National Center for Supercomputing Applications, which theoretically could be dangerous in this regard but in practice doesn't concern itself with such things.
Good physical noise is easy to generate (Score:1)
OK, so the noise may be pink rather than white, but you can whiten it by a variety of means, and anyway, pinkness doesn't matter as far as OTP algorithms are concerned: you still can't infer the next bit in a sequence as long as your key bandwidth is (substantially) greater than your data bandwidth. Given that proviso, knowing that the noise is pink doesn't help the cracker at all.
Re:Looks OK, but the problem with 1-time pads is.. (Score:1)
Re:you need a completely *random* key (Score:1)
Cascading PK crypto with N-OTPs (Score:1)
Cascading more than one such algorithm together can produce a weak result, but this is not the case when you cascade one with an ideal OTP (it creates total obscuration of any cryptoanalytic weknesses in the applied algorithm). Of course, it would be pointless to do this in an ideal world, cryptographically speaking, since in theory you cannot improve on a OTP. However, N-OPTs are not ideal OTPs, so such algorithms (especially PK ones) can significantly increase the functional parametrization space.
As always though, remember to keep the key bandwidth substantially greater than the data bandwidth, eg. sample any physical noise infrequently. [Don't forget to attach an alert to your noise generator too so that you know when it stops making a racket: trannies, diodes and your parallel port do die occasionally, and that can be cryptographically embarrassing.]
Eay way to not loose the key... even if you format (Score:1)
Personly, im using a 12mb porn video from one of my favorite sites that im keeping on a PGP encrypted disk. its a large site, so im sure its not going under before the next time I get a wild hare and chnage encryption schemes to thow off the guys I hear breathing on my line.
Also to deal with the size issue, cant it use looping data? i.e. if your key is taco, cant it just XOR with tacotacotacotaco untill it reaches the EOF of the file to be encrypted? Granted its a little insecure, but think of the odds if your encrypting a 2gb disk with a 100 meg key?
Re:Some thoughts on encryption (Score:1)
It's really difficult to write a software package that contains hardware
Anyway, Intel's Willamette chip has a hardware RNG. I think Intel will be supporting it on Linux.
you need a completely *random* key (Score:1)
If you can find a way to generate and securely distribute an OTP (e.g. sending it by courier to your embassy, or handing it to the captain of the ship you want to communicate with while it's at sea), it may be a good idea to encrypt the key and possibly even the messages you send anyway. This doesn't reduce the security of the scheme to the security of that encryption, because you still want to obey all the normal rules you would with an OTP. But it does add an extra layer of security, in case the OTP is compromised - which is a risk, considering that both parties will need to store the OTP on disk/tape somewhere. (and remember how everyone always tells you not to write down your passwords).
Re:Some thoughts on encryption (Score:1)
Even the computer's fan should be enough to make this unbreakably random.
Snake Oil (Score:1)
But they say to use the OTP "over and over again." (Score:1)
The documentation states that once a key file of a given size is generated, it can be used "over and over again." If I remember correctly, an opponent who has two ciphertexts that were XORed with the same "OTP" can trivially recover the key (though I forget how.)
Hmmm, I should go dig out my Applied Cryptography. It's covered in there somewhere.
Re:Why people don't use one time pads (Score:1)
Just twice? How?
Here are two strings of numbers. I obtained them by xor'ing the ASCII of two English text messages with the same sequence of random numbers. What are the plaintexts?
[171, 61, 38, 69, 203, 212, 243, 134, 223, 99, 169, 83, 117, 243, 27, 89, 194, 8, 227, 145, 248, 41, 131, 25, 77]
[177, 58, 56, 22, 131, 216, 242, 195, 139, 98, 191, 83, 103, 242, 12, 10, 197, 77, 237, 155, 229, 62, 194, 13, 92, 10, 255, 249, 28, 211]
Even if you can't do this, in general I take your point, though.
Alex.
Compressed files as random data? yeah right... (Score:1)
file
All compressed headers are the same per compression type
re: running out of OTP data (Score:1)