## Comment Re:Cost? (Score 5, Informative) 191

Diesel bug is a thing.

That's actually another reason for regular generator tests in backup facilities:

It frees up storage volume that can be filled with fresher fuel.

Check out the new **SourceForge HTML5 internet speed test!** No Flash necessary and runs on all devices.
×

Diesel usually cannot be stored for longer than one or two years:

Diesel bug is a thing.

That's actually another reason for regular generator tests in backup facilities:

It frees up storage volume that can be filled with fresher fuel.

Diesel bug is a thing.

That's actually another reason for regular generator tests in backup facilities:

It frees up storage volume that can be filled with fresher fuel.

How the hell are you going to fence a Bugatti Veyron?

Longswords?

I concur. So what exactly is the point of and usecase for having that weapon?

...and how many of those guns had > 100 mile range with 50 meter accuracy?

Zero. these are not in the same class of gun, except they are 'big' and on 'ships'. One is meant for pin point accuracy, the other is meant for wide-scale destruction.

Well... for a nuke, 50m CEP is indeed pretty much pinpoint, considering that its destructive radius

is 10 to 100 times larger than that.

For those projectiles, 50m CEP is *lousy* and not even close to "pinpoint", and means

you're more likely than not to bomb the wrong house. In other words: It is useless if what you

want to destroy is smaller than a city block (while leaving its surroundings standing).

Pretty sure you're thinking of Sonar, not Radar, which as the OP says, does use lots of power (and a vacuum tube, which means a separate high voltage power supply, no such thing as solid state radar, because SS can't handle the power needed).

Welcome, time traveller from the 1970s, to the year 2016, where 3.3V low-power solid-state radar most definitely is a thing, and is mass-deployed in cars and other moving objects.

Jesus... is he a wave, or a particle?

I don't know, but I heard that he saves, although no one seems to be able to tell me what interest rate he's getting.

I always assumed that to mean backup, not deposit.

I was doing similar calculations for an A-380 but I doubted my results as they pointed to rate of energy recovery being in the order of a small power station for 10 seconds.

Which probably means that your calculations were correct, it has to dissipate energy at a rate of at least

dozens of megawatts.

Max landing weight of an A380-800 is 391000 kg, landing speed around 140 knots (72 m/s) - note that

this is airspeed, so ground-relative velocity can be slightly lower. Still, the hardware has to be designed to

handle the maximum case.

This results in a kinetic energy (1/2 * m * v^2) of nearly exactly 1 GJ.

So to stop in 10 seconds, energy dissipation has to happen at a rate of 100 MW. Douple the stopping time,

and it's still an impressive 50 MW.

A single brake on an A380 wheel can handle a 5MW braking (once, in an emergency).

An A380 has brakes on 16 of its 22 wheels. Add the other deceleration systems (spoilers, reverse thrust),

and a complete A380 can probably dissipate kinetic energy at a rate of a considerable fraction of a

gigawatt in case of a last second rejected takeoff (faster and quite a bit heavier than the worst-case landing).

That isn't a *small* power station anymore.

You can't test a full H-bomb under ground. It wouldn't stay under ground.

Phew - I'm glad all those full H-bombs tested underground didn't know that at the time.

citation required. Pu238 has never been used in a pacemaker.

Citation

From that page: "Common markings: Pu-238".

Hmm... I read that and, well, I noted the part below your link. Namely, the problems section. Allow me to quote, if you will and do not object, to your own link:

Despite Shannon's proof of its security, the one-time pad has serious drawbacks in practice because it requires:

Truly random (as opposed to pseudorandom) one-time pad values, which is a non-trivial requirement.

Drawbacks? Yes. Unsolveable ones? Absolutly not.

There are several natural processes that can be used to generate

random numbers (without pseudo-): Radioactive decay, thermal noise,

cosmic rays,

It's quite bothersome indeed to generate a useful amount (gigabytes+)of

randomness, but it is in no way impossible, and actually routinely done for

cryptographic purposes.

Also, this but not as important:

The theoretical perfect security of the one-time-pad applies only in a theoretically perfect setting; no real-world implementation of any cryptosystem can provide perfect security because practical considerations introduce potential vulnerabilities.

That's extremely weasel-wordy and gives no example of a vulnerability. This paragraph

should be removed as being totally content-free.

Yes, one shouldn't lose the OTP. Also, it is strictly forbidden to reuse it.

But beyond that, OTP crypt is really easy to implement and quite hard to screw up.

I surmise that, simply, the proof is wrong as we have no true random and may never have true random. Hard as fuck, yes. Perfect? I object.

What kind of a mathematican are you, exactly? There are very few absolutes

anywhere - mathematical proofs being one of the few notable exceptions. Once

something is proven in its system of axioms, it is absolutely and irrevocably true.

I'm close to giving up on you here...

If you send a cypher via OTP and someone goes and kills Harry then, by reasonable conclusion, with enough time - we can find that you, who sent the message, told that someone to go kill poor Harry

But not by breaking the intercepted ciphertext. You either get a confession, or find the OTP used.

The ciphertext alone is useless to prove any kind of message content, even with infinite resources.

Random does not, as far as we know, exist. What we do have are probabilities. They are not the same.

Random exists all over the place in nature.

So, it's useful but is it *truly* unbreakable if the message is "GOKILLHARRY" or the likes? By truly unbreakable, I don't mean damned hard - I mean truly unbreakable, that it can *never* be solved?

YES! Provably (and proven) so!

(provided of course that your cipherstream stays secret.)

Again, in a OTP-generated cipherstream, *there is nothing to solve*.

It's random noise. Structureless. This is not an algorithmic cipher where the cipherstream

suddenly makes sense once your brute-forcing hits the right key bit-pattern. It's a random(!)

bitstream that, if XORed with a pre-shared key known to Alice and Bob, results in * a * plaintext.

But all other plaintexts generated by all other possible keystreams are equally likely, and the

"real" plaintext is in no way special. So

And to DOLOVESUSIE.

And to JABBERWOCKY.

And to HOMOGENIZED.

And to ITINERARIES.

And to Fa4dohwaraM.

And so on.

None of which can be identified (ever! mathematically proven!) by an attacker as being the

plaintext that was sent. All plaintexts are equally likely (I'm repeating myself...).

You have to let go of the idea that there is a correct key that can be found (and recognized as

being

the message sent), or that there are some very difficult but theoretically possible calculations can

be made to identify the plaintext.

There isn't. There aren't.

OTP-encryption is different from all other encryption methods that way:

The only "algorithm" used is XOR, and there is nothing to break here.

Once there is a properly random OTP bitstream known to sender and recipient only,

and they don't lose that OTP to an attacker, the cipherstream is eternally secure.

It is - to repeat myself again - just random noise.

Thank you for your patience, by the way. It's hard for me to grasp the idea that there's something (like this) that math can not do - eventually.

Even better: Math has been used to proove that math cannot do it.

Maybe, before I die, I'll make a random OTP and cypher the digits to a Swiss bank account and whoever gets it right (and the password) will get the money in it. I guess I could do GPS coordinates.

That is equivalent to not publishing anything and just saying "whoever guesses the secrets

in my head wins", so people would have to brute-force account number and password by

running all possible combinations through the bank's customer desk. They might allow a

second try, maybe even a third - but then one will be politely and firmly escorted outside.

In other words: If you do that, you are donating the money to the bank. Forever.

I'm going to have to take your word for it but I am a mathematician and I don't really think we've got anything that's truly random. We have unpredictable pretty well covered but not true random. That's why most anything is a PRNG or CSRNG.

Yeah, OK. **However:** You being a mathematician, it should be clear to you that

"the amount of randomness" in an XOR operation is always the one from the more

random side (XOR preserves randomness) - that's why XORing multiple sources of entropy

never makes the randomness worse.

So the entropy of the ciphertext is equal to the entropy of the OTP keystream, and *none* of

the structural properties of the plaintext survive.

But it seems likely that, with enough time and enough compute power, that if you sent a message to Tim and Tim burned down a house we'd be able to throw out any results that look like the Mona Lisa.

No, it doesn't. No, we wouldn't.

The Mona Lisa, "burn down that house", "defend that house at all cost", "paint that house

blue with pink flowers", and "build a monument to our eternal noodleness" *are all equally valid*,

and you have no way to prove that your "deXORing", even if it *is* the original plaintext,

is the original plaintext.

The sender will always be able to provide a keystream that deXORs to "defend that house at all cost".

Again, trying all possible keystreams on a cipherstream is *mathematically equivalent* to just

pulling random bitstreams of the same length out of thin air. This has nothing to do with the amount

of computing power you have, which would just allow you to generate all possible messages faster -

without helping you at all to find the real one.

Without the original keystream, **there is no message in the cipherstream**.

Thank you and that confirms that I had thought to understand but can't one still crunch and then look at, systematically, to throw out all probable gibberish and then use machine learning, or similar, to make probable guesses and then keep refining either by human, circumstance, or additional metrics to reduct the probable answers until you can make a few educated guesses?

No. One-time-pads are *random*.

There is nothing in the transmitted ciphertext to even start any kind of probablility guessing.

The ciphertext you get by XORing the message with a random number of equal length is itself a

random number.

Of course, you now can generate random numbers of said length yourself and try them on the

ciphertext, but this is *mathematically equivalent* to just generating random *cleartext*

messages, without any input at all.

If you have some bits of intercepted ciphertext, all "decryptions" (really just an equal number

of randomly generated bits) are equally likely: A PDF version of the Bill of Rights, an animated

GIF of goatse, a rickroll video, random noise (lots), a JPEG of an upside-down portrait of Gandhi chasing

Roger Rabbit, Dick Cheney's voice calling for friday prayer...

It's the infinite monkeys on the bit level. And there is *absolutely no way* to tell which one is "correct".

Note that, for example, Google's cars are never going faster than 25 mph.

This is incorrect.

Google's Lexus-based self-driving cars are driving on highways, going highway speeds:

https://www.youtube.com/watch?v=TsaES--OTzM

"Our vision is to speed up time, eventually eliminating it." -- Alex Schure