ec2-3-230-143-213.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

This page links together crypto-related people and things. Click title to see some.

See also:

Common misunderstandings:


People who say "nothing except OTP is secure" should [probably read this].
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
Man-in-the-middle attack? How, precisely? - MoonShadow
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.
Yeah.  Blueshell is amused at PhamNuwen?'s belief in PublicKey Crypto. -- Senji
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

CategoryCategory | CategoryTimeSink | CategoryAbbreviation | CategoryWeb | see also PrivacyMatters

ec2-3-230-143-213.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic
Edit this page | View other revisions | Recently used referrers | List subpages
Last edited June 19, 2006 10:56 am (viewing revision 43, which is the newest) (diff)