Cryptography is a tool to be used to help secure things. A house is not made safe just by making sure you use a good hammer; systems are not magically made secure just by introducing crypto. The entire system, including the interactions with human beings, must be taken into consideration.
OTP is only secure if key material is never reused (otherwise it's not an OTP, is it?). OTP is not secure if key material can be predicted by the attacker; notably, if key material is generated using a PRNG or a cipher output, the resulting system is only as secure as the PRNG or the cipher, and calling it an OTP is incorrect.
Nothing except OTP is theoretically secure. This does not render everything else useless. Balance security costs against your expected attackers and the resources they would be willing to dedicate to breaking your security. The costs of OTP are very high, and rarely justified.
It does say in that paragraph that "The costs of OTP are very high, and rarely justified". Vinge's A Fire Upon The Deep early on has two of the major characters shipping 1/3 of a OTP around for reassembly at the target.
Mmmm.. I remember that. There was ots of 'how suspect is this transmission given that 1/3 of the pad may have been compromised' stuff. Which leads to - why not ship one time pads around with every normal movement? Bits are pretty lightweight, after all. --Vitenka
There was an interesting suggestion a while back - have a publically available source of random data that produces more data per X time than can be stored by your expected opponents. To communicate, encrypt your message, wait (X + random amount) time and send. The key is the time at which the message gets encrypted; the key is agreed on in advance. - MoonShadow
Somewhat vulnerable to DOS attacks, surely? One small hiccup in the transmission - reciever is unable to connect to the random data source in time, and blooie it's gone. Also, either the data rate would have to be very large (leading to a required large key size to give an accurate enough start time) or x would have to be very large (making it useless for timely communication) - interesting idea nevertheless. --Vitenka (but, fundamentally - you've still got a shared secret key, many bits of which can be guessed, because the progression of times chosen is highly unlikely to be very random)
... which Kazuhiko initially mis-read as "because the progression of time is highly unlikely to be very random" ^^;;;
Two problems - if you can agree the key in advance, you can just as easily agree a one time pad in advance. Secondly, someone can eavesdrop on your communication with the data source, and thus can store just the randomness from the time that you pick up. The fact that the data's too expensive to store means that it's too bandwidth expensive to listen in at random times just to try to fool the hypothetical attacker. --Angoel
Well, I presumed the point was to increase a small secret (an agreed time) into a much larger one. You can also give the time of the next message in the first one - and thus infinitely propagate. That is something you can't do with a OTP (which can, after all, only conceal as much information as it itself contains) You're dead on on the 'watch them when they pick up the key' problem though - although, if they are surveilling the recipient, they could just wait until he decodes and reads the message... --Vitenka
There are many ways that people claim they can increasing a small secret into a bigger ones. They all seem to rely on some outside form of 'randomness' - the choice of a particular hash function, a certain method of obfuscation, an external source of randomness. I'm not sure I'm convinced. --Angoel
Except this one doesn't have to rely on a computed source of randomness like a hash function. So long as the source is publically available, you can use anything you like. - MoonShadow
Hmm. As an aside, approach also has the problem that a man-in-the-middle attack would be pretty effective (although standard encryption could help protect against that (so if you trust standard encryption, why aren't you using it instead of this randomisation stuff)). You'd also have to completely trust your 'random' data source. --Angoel
Vinge's characters probably have to worry about attacks that we don't really - (for instance) exhaustive search for a 128-bit key is pretty impractical in the real world (even at 10^12 keys a second, which we won't be able to do any time soon, you've still got 10^19 years to wait) but that might well not be the case in the high Beyond.
Why can't you just append a new OTP to the end of the message before encrypting with the current OTP? This would in no way contribute to the crackability of the message as the OTPs are statistically random, and yet would practically eliminate any worries about transferring OTPs - once you'd sent someone the first OTP, the rest would be undiscoverable. The only problems are 1) access to an element of the OTP chain potentially hands over the entire chain to the attacker, 2) transferring the original OTP securely would be a whole new ball game and 3) the system would double the overhead (although that's a comparatively small price to pay). Any thoughts? - CorkScrew
... the security of OTP encryption is only perfect if a single bit of pad is used to encrypt a single bit of message. So your second pad eats as many bits as it gives you. Block ciphers can be expressed in this manner, though. --Vitenka
But the second pad would be random so you could use the first pad on both it and the message being carried without increasing the amount of information available to the attacker. It would be no more crackable than using the pad to encrypt just the message - CorkScrew
I think that the system allows the attacker to brute-force your original OTP. An attacker knows all the intermediate OTPs in their encrypted form, so this approach is only slightly more secure than just using the original random sequence on all messages. --NT
If you reuse a pad, it is not secure. If you do not reuse the pad, you gain nothing. - MoonShadow
Doh, you're right ***slaps forehead***
Anyone know anything about EllipticCurve? encryption? I'm looking to add to my newly-written python RSA library. - CorkScrew
Simple as RSA to write, a world of pain to optimise, IIRC. No, I can't really tell you any more offhand than Google throws up anyway. Oh, you might find it useful to conform to a [standard]. Oh, the [Wikipedia article] seems to have everything one might need anyway - MoonShadow