US Navy Tests WWII-ERA Messaging Tech: Dropping Bean Bags Onto Ships (popularmechanics.com) 95
Long-time Slashdot reader davidwr writes: In World War II, pilots would air-drop messages onto ships using bean-bags. Just as with sextants a few years ago, the Navy is bringing back old tech, because it works.
Just as during the Doolittle Raid of Tokyo, the purpose is to prevent eavesdropping. You can read more about the modern bean-bag-drop on Military.com or Popular Mechanics. There's a video about the Doolittle Raid hosted at archive.org with bean-bag-drops at 2:39 and 5:19 into the video. I wonder how many high-density SSD drives fit in a standard Navy bean-bag?
"In a future conflict with a tech-savvy opponent, the U.S. military could discover even its most advanced, secure communications penetrated by the enemy," notes Popular Mechanics. "Secure digital messaging, voice communications, video conferencing, and even chats could be intercepted and decrypted for its intelligence value.
"This could give enemy forces an unimaginable advantage, seemingly predicting the moves and actions of the fleets at sea with uncanny accuracy."
Just as during the Doolittle Raid of Tokyo, the purpose is to prevent eavesdropping. You can read more about the modern bean-bag-drop on Military.com or Popular Mechanics. There's a video about the Doolittle Raid hosted at archive.org with bean-bag-drops at 2:39 and 5:19 into the video. I wonder how many high-density SSD drives fit in a standard Navy bean-bag?
"In a future conflict with a tech-savvy opponent, the U.S. military could discover even its most advanced, secure communications penetrated by the enemy," notes Popular Mechanics. "Secure digital messaging, voice communications, video conferencing, and even chats could be intercepted and decrypted for its intelligence value.
"This could give enemy forces an unimaginable advantage, seemingly predicting the moves and actions of the fleets at sea with uncanny accuracy."
Pneumatic Tube (Score:3, Interesting)
It's probably time for a revival of pneumatic tube communication [explainthatstuff.com]. The tech is actively in use at drive-through bank tellers. It should be revived for general use.
Re: (Score:2)
Much better to try it before
Re: (Score:2)
How else am I to know that the 12 pack of boxers aren't going to work out for me until I wear all twelve of them at least once.
Also: to keep them as new as possible, I returned them unwashed. Thanks, amazon!
Re: (Score:2)
They still had one for US Mail 20 years ago in Portland in the building that Tripwire Software was (is?) in, but it had big warning signs on it not to use it for anything important.
It was about that long ago that my bank replaced theirs with drive-up ATMs, with a teller only in the lane by the building.
Re: (Score:2)
Is that you DZ-015 [youtube.com]?
Re: (Score:3)
Ah, no, but I can see the confusion.
That's the QA department.
Re: (Score:2)
Nah, not high tech enough. It would be better to marry it with talking rodents. You tell the rodent what to say at one end, shove him in the tube and hit go. The guy at the other end receives the rodent and gets a voice mail message. Responding is optional but generally follows the same pattern.
Re: (Score:2)
Multi-kilometre reels of pneumatic pipe can reel-in and reel-out, but they're cumbersome. By the time your fleet is in the middle of a decent ocean, the fleet of auxiliary vessels carrying the spools will probably out-mass the fighting ships.
Of course, no enemy would be so unsporting as to fire at the reel-freighters, sending shrapnel
Re: (Score:2)
Yeah but.. (Score:1)
Doesn't the concept of physically dropping a message come with inherant dangers? Such as not being entirely sure the message came frome home base, or that it hadn't been tampered with?
Admittedly I just read the submission, and not TFA.
I wonder if acceptance of that sort of compromise comes from experience. You know, it might be better to use instinct to trust accuracy as opposed to assuming validity because the tech would make any other possibility mathmatically "impossible".
Re:Yeah but.. (Score:5, Insightful)
If an airplane is able to fly over your ship and drop stuff on it, when you're not even sure if it was your aircraft, you've already been sunk and none of that other stuff matters.
Re: (Score:3)
Re: (Score:2)
Doesn't the concept of physically dropping a message come with inherant dangers? Such as not being entirely sure the message came frome home base, or that it hadn't been tampered with?
I'd think this sort of thing could be worked around with reasonable confidence of security. Such as an in-person agreement ahead of time that important operational messages to be dropped this way would include some random set of rotating phrases.
Re: (Score:3)
Re:Yeah but.. (Score:5, Funny)
Such as not being entirely sure the message came from home base, or that it hadn't been tampered with?
I think you've got bigger security problems if you let a compromised aircraft drop something on your deck.
Re: Yeah but.. (Score:1)
I dont disagree, i think you all make great points. I wont lie...
I guess im fixated on the beanbag itself, and i might be looking at the problem from an angle innappropriate, since encryption helps deal with this problem. Maybe it will somehow be combined...
My statement had less to do with explicitly how rhe payload got there, and more to do with the payload itself. I guess i see the plane being just part of the solution, and the protocol overall having more physical points of failure.
Re: (Score:2)
Yeah, so how do you set up that drop? With the previously intercepted communications. And now that the enemy knows this, as soon as that order goes live, we're flying our own plane over that ship and dropping the biggest fucking bomb we can carry.
Because if you don't clear that drop ahead of time, the allied plane is going to get shot down. And if you clear that drop via intercepted communications, the bean bag might be a big boom.
So yeah, now we need to send eyes out to check the incoming plane, and hope t
Re: (Score:2)
Doesn't the concept of physically dropping a message come with inherant dangers? Such as not being entirely sure the message came frome home base, or that it hadn't been tampered with?
Not to mention the possibility of a drone-in-the-middle attack.
Re: (Score:1)
That is kind of exactly my point, should a drone, jar jar, or anything else alter the message prior to it being read, its left to humans to make that determination...
but is that the point? has point to point encryption left us docile? the way I understand it, is with current tech a communication might be intercepted, but even if it could be read and modified, it would be signed differently, leaving the payload not legible (unless the attacker had access to the key)
my question is if this change actually red
You don't have to not use encryption. (Score:2)
All these problems have been solved fairly well with public key encryption. The flaws with that largely come with insecure software doing the algorithms, things like compressing the data before you encrypt it, leaking information about the data through the size of the ciphertext. Reduce access to the cyphertext, by delivering it by sneakernet, and you solve those problems.
So the data in your beanbag can be cryptographically signed, by a device that is kept, permanently air-gapped, in a multi-key safe in the
Re: (Score:2)
You're far from the first person who didn't realise that strong verification of the o
I've seen similar ... (Score:5, Informative)
... efforts in law firms.
I'm retired IT from several. For particularly high-dollar cases, parties agreed to snail mail, fax machines, landlines, and personal visits. When an outcome is expected to favour someone with, say, 138 million dollars, the court allowed no digital transmissions until after the case settled.
Re: (Score:2)
A fax goes through a telephone line, which is generally assumed to be much less likely to be tapped than an Internet connection. Those assumptions are less valid now than they used to be as more people switch from POTS to VoIP.
For the same reason, doctors send things by fax that they won't send by email, though email is particularly insecure because not only is it transmitted in plaintext through unknown third parties, it may sit on various servers with histories of security breaches.
In short, there are mo
Generally assummed, but it is a wrong assumption. (Score:2)
How fax gets a pass, or has ever got a pass, when it comes to secure communications is beyond me. Fax transmissions are easily faked, easily intercepted, easily disrupted. I mean, once I was setting up a computer modem to work as a fax, did a test to a remote location, thought everything was right - until I noticed that the fax I thought I sent to another building, and had confirmation that was received, was actually sitting in the tray of the fax machine across the room! The local fax had heard the tones,
late-1980s faxes were reasonably secure (Score:2)
Not counting the odd scenario you discovered, a fax sent and confirmed-received by both a machine and a human in the 1980s was almost certainly not intercepted and almost certainly did not have a fake origin.
Why?
* In practice, POTS lines were rarely interecepted and long-distance traffic was impractical to intercept without technical assistance from the long distance companies.
* If the receiving line had caller-ID and the fax machine logged it, the human at the other end could and should compare the caller-
Re: (Score:2)
Computers, and anything computing related is absolutely the least secure thing on the planet. Screaming secret messages across a lake is more secure, than ever using a computing device. You literally can not make a modern computer, modern switch, modern backbone secure. Ever. It just can't be done.
That's a little bit paranoid. Build your own hardware for Oberon, then hand-compile the software, or verify the compiler output. Basically zero chance that the device will then be vulnerable to something. Sure, you wouldn't be able to use it for many "normal" things, but for a secure proprietary communication device? Not a problem there.
Re: (Score:2)
I get the impression that you think vulnerable code "happens to other people". That the "bad code" comes from the compiler being buggy, or compromised??
It mostly comes from being way bigger and/or more complex than strictly necessary. "Way bigger" in this case meaning roughly a factor of 10000x. *That alone* means 10000x bigger potential for problems.
NO! The truth is, it is literally impossible to write secure code. Ever. Hell, to even *start*, you'd need to develop all the hardware, including CPU, all chips, from scratch.
You clearly didn't even bother to read my suggestion, otherwise you wouldn't propose this as some kind of novel idea. Especially when I've just suggested that.
And somehow be absolutely perfect at that.
No, actually not. For example the most recent hardware problems mostly stem from engineers being overly clever. Again the problem of complexity rears it
Re: (Score:2)
I'm not trying to insult you here, but.. either you're not a coder, or you're a very bad, scary coder. Because you seem to think that it's easy to write exploit free, bug free code.
Show me something, anything that's been deployed, exploit/bug/etc free for 5+ years, widely used, real world tested by fire. You can't. At all. Every router, switch, firewall, computing system, all of it. Exploited, or with known exploit vectors. Every. Single. Thing.
It isn't easy but it is possible to write exploit-free, bug free code. Most of the code I've worked on in my career hasn't been widely deployed for 5+ years, but I have one example which has. In the 1980s when I was with Digital Equipment Corporation I worked on EDT version 3, which ran on the PDP-11 and VAX. We wrote it carefully and tested it throughly. Just before I left DEC we ported it to Alpha. In 2014 I saw it running in a hospital in New Hampshire. The hardware was new but the software was rec
Re: (Score:1)
I'm not trying to insult you here, but.. either you're not a coder, or you're a very bad, scary coder. Because you seem to think that it's easy to write exploit free, bug free code.
Show me something, anything that's been deployed, exploit/bug/etc free for 5+ years, widely used, real world tested by fire. You can't. At all. Every router, switch, firewall, computing system, all of it. Exploited, or with known exploit vectors. Every. Single. Thing.
It isn't easy but it is possible to write exploit-free, bug free code. Most of the code I've worked on in my career hasn't been widely deployed for 5+ years, but I have one example which has. In the 1980s when I was with Digital Equipment Corporation I worked on EDT version 3, which ran on the PDP-11 and VAX. We wrote it carefully and tested it throughly. Just before I left DEC we ported it to Alpha. In 2014 I saw it running in a hospital in New Hampshire. The hardware was new but the software was recognizably the same--almost 30 years later it was still being used and, as far as I know, still bug-free.
You're mixing up 'bug free' with 'known to have bugs'. Are you seriously going to claim, that if somehow that piece of software was the gateway for $300 million in bitcoin, that no one would ever discover an exploit? Further, here's what most people don't seem to be getting, there are right now, literally thousands of currently used remote-exploits in current code, that security researchers have not discovered yet.
There's literally been bugs in code, in kernels, routers that have say fallow for *more than
Re: (Score:1)
You CAN have proven-secure computer communications (Score:1)
Thing is, there *is* no "properly done computer communications". Ever. Anywhere
For everyday use, you are probably correct, but for special purposes, such as military communication, you are just plain wrong.
You CAN have provably correct computers, and these can be used to provide securely encrypted communications. Well, as secure as the keys and the underlying algorithms that is.
The trick is you have to keep things simple, from "first principles" on up.
You can, in principle, make a modern-public-key-algorithm encoder and decoder on silicon that takes data and keys from an input, say,
Re: (Score:1)
There are forms of encryption that have been studied for decades such that we have a very high confidence we know where the vulnerabiliteis are, like what makes a good key and what makes a bad key.
As for coding bugs and implimentation bugs, if your algorithm is simple enough you can write provably correct code. As far as the negotiation stage, I would make the same claim: There are encryption algorithms that have been well-studied for decades and we have high confidence we know where the vulnerabiliteis a
Re: (Score:1)
Decades of very trusted workers did that around the world.
Now its news again?
Re: (Score:2)
Re: (Score:2)
One time pad is a better solution in my mind.
You are completely missing the point.
The concern is not the enemy decrypting the messages, but RF transmissions giving away the position of the fleet.
The navy regularly runs radio-silence drills for days at a time, relying on semaphore flags and signal lamps. But those have limited bandwidth and are ship-to-ship, not aircraft-to-ship.
Re: (Score:2)
Re: I'm torn (Score:5, Informative)
The summary specifically talks about decryption of communications.
The summary is wrong.
TFA at Popular Mechanics is also wrong, and is just an incompetent rewrite of the Military.com article which doesn't mention "decryption".
Semaphores, signal lamps, and beanbags are NOT about avoiding decryption. They are about avoiding DETECTION.
They can't be detected, they can't be jammed, and they can't be triangulated.
Re: (Score:1)
Semaphores, signal lamps, and beanbags ... can't be detected, they can't be jammed
The plane carrying the beanbag can be detected and shot down, "jamming" the communication.
If I suspect you are somewhere near point A and trying to use a semaphore or signal lap to communicate with someone near point B, and I have enough control of the land, sea, or air beween those areas, I can put up smoke or artificial fog to jam your communications. I may even be able to intercept them if I have enough information and control of the area in between.
Re: (Score:2)
The navy regularly runs radio-silence drills for days at a time, relying on semaphore flags and signal lamps. But those have limited bandwidth and are ship-to-ship, not aircraft-to-ship.
And by "signal lamps", when you say "limited bandwidth", you mean some hand-operated devices? It's not like we couldn't squeeze much more bandwidth into the same light flux. Hell, even photophones are ancient stuff.
Re: (Score:2)
EMCON (Score:2)
One word. It's in my subject line.
Re: (Score:2)
It sounds like a last ditch solution that increases the probability of successful communications when all else fails. It won't hurt to have the procedures worked out in advance.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Really? Tell us how you plan to intercept a beanbag drop over open water against a USN ship that you likely don't know where it is, and a USN plan that's likely being watched by AWACS and within navy fighter jet protection.
It's not like it's something they'll use all the time either. It gives them another tool, and having a large toolbox = good.
Re: (Score:2)
Could I just ask a personal question - is your number of days stuck on a boat because the weather is too bad for helicopter flight more than 100 days, or less?
To get close enough to be confident of getting a bean bag onto the deck, you're talking about helicopter landing weather quality. In some areas that I've worked, the helicopters can operate on average one day in two or three. So, your p
Re: (Score:2)
It is still an increased probability. I never said anything about perfect reliability.
Of course nothing says they can't make more than one attempt. Splashing a beanbag is nowhere near as bad as crashing a helo into the deck.
Re: (Score:2)
I feel like your analysis was made by a person ill suited to analysis. Your premise that this is a replacement method rather than an additional option in cases where the pros and cons are considered is where you went wrong.
Re: (Score:2)
Re: (Score:1)
Their fancy media player is infected in port by a new "friend", a contractor.
They use it every time on duty due to "boredom", missing the comforts of civilian life.
The consumer junk is not removed and allowed to keep crew numbers happy on active duty.
Crew members have habits like "talking" out loud the message that's decoded... as part of the buddy system to ensure quality and security.
Compre
HOWTO: two way communications (Score:2)
Drop bean bags with one time pads then you can send back via radio. There is the problem of assuring that the drop is from friendly aircraft, but that can be done by sending the ship a 1 MB message encrypted with some random part of the dropped one time pad.
I assume that ''the enemy'' already knows where the ships are so sending radio does not give much information.
Re: (Score:2)
Re: (Score:3)
Even so, you have to be prepared for the eventuality that the petabyte of OTP had been comprised by some Greenglass, Rosenberg, Walker, Mak, Pollard, Snowden, Manning, and many others. Every country has a list just as long of people who sellout for whatever reason.
Re: (Score:2)
Re: (Score:2)
Navy also switched from touchscreens (Score:5, Insightful)
Re: (Score:2)
for throttle control back to mechanical.
Nope. The controls are still electrical, just the switch is mechanical ... and a big array of mechanical switches is actually less reliable than a touchscreen.
There were several collisions in the Western Pacific, and the Navy was under political pressure to "do something". Rejiggering switches allowed them to do that, rather than addressing the real problem (poor training and procedures). Blaming the UI design was prefered over blaming captains and admirals.
Re: (Score:2)
a big array of mechanical switches is actually less reliable than a touchscreen.
That depends on which OS [wired.com] you use for your touch screen. A single app dividing by zero causing the whole OS to crash? We hadn't lost a carrier to a zero [ytimg.com] since WWII.
WinNT did not crash ... an application crashed (Score:2)
That depends on which OS [wired.com] you use for your touch screen. A single app dividing by zero causing the whole OS to crash?
Nope. Didn't happen. The OS did not crash. Bad data was entered into a database. That bad data was sent to an application. That application crashed. That application was supposed to operate the engines.
WinNT, Linux, neither operating system prevents applications from crashing.
The article that started this urban legend was retracted for being inaccurate. The developers of the applications software admitted it was their problem not the operating system. Although they do point out everything was in a tes
Re: (Score:2)
and a big array of mechanical switches is actually less reliable than a touchscreen.
Is that so? Did you compare the MTBF numbers of high-end mechanical switches with high-end touch screens?
Re: (Score:2)
What Drolli said. Take a look at a simple example these days...washing machines. They're less reliable than much older versions. My grandmother and mother had their machines for decades w/o issue. I've personally been thru three machines that are modern, and have been told by the repairmen that they all break frequently. Maybe it's planned obsolescence.
Re: (Score:2)
Yes, training would help...as would not confusing touch screens with intuitive controls that won't get misused during an emergency. Guess what, during an emergency, not everyone is calm, cool, and collected and makes totally correct decisions on a touch screen overblown with extra "features".
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
As someone below mentioned, the throttle control is merely human input, not directly implementing the control of the motors.
Along the same delusional notions of mechanical superiority, la Presidenta Tweetie wants the Navy to replace the catapults on the new aircraft carriers with hydraulics because one has to be an Einstein to understand how to wire up catapults powered by energy from nuclear reactors...with their spare capacity and thus adding miles of hydraulics to those big fat ships. Sheesh, I guess the
Re: (Score:2)
Re: (Score:2)
Hussein beanbags (Score:3)
Just don't buy any beanbags from huawei
Typewritter (Score:2)
Re: (Score:1)
The ball-type typewriters are relatively easy to eavesdrop on.
I think the every-letter-has-a-hammer type ones can now be eavesdropped on as well.
However, if you do your typing in a soundproof room you should be okay. If it's an electrical typewriter, run it on a battery in an RFI-hardened room.
If reading handwriting isn't an issue, just use a pen or pencil, it will be easier. Just make sure nobody and no camera can observe your hand moving as you write.
Typewritters are vulnerable (Score:2)
Then one should use a typewritter in order to avoid the message being eavesdropped while been typed
Typewritters are vulnerable. By moving to old school tech you are just moving the exploits back to old school too.
The eavesdropping still occurs, its just after the typing. The "ink ribbon" is essentially a copy of what has been typed. It may be easier to smuggle out than a stack of papers. Plus there are the human errors where they are thrown into the normal trash rather than "properly" disposed of, or other failures of proper procedures. The famous Enigma project of WW2 relied heavily on enemy operator
Sounds Like (Score:2)
Sounds like one of those university engineering projects where they tell you you're designing a drone control system to help aircraft drop water on fires or drop messages to stranded boats or some other humanitarian goal, but you know the actual application will always be dropping bombs onto enemies.
I can IMPROVE this! (Score:2)
We load the data on a USB flash chip, place it in a tube that is inserted into a +120mm mortar shell, and then just point the sight at your target ship and press FIRE!
The captain will know a message has arrived by the loud thump and subsequent dent in his cabin wall. And that's interrupt based so its extremely efficient.
Early (current too? dunno) spy satellites too. (Score:2)
I heard the early spy satellites both avoided data interception and achieved phenomenal bandwidth by recording their info on film and occasionally deorbiting a canister.
Story was that it would re-enter near Hawaii, and an airplane would catch it as it did the last few thousand feet of its drop (to keep Russian submarines from grabbing it, as they no doubt would if it were allowed to hit the ocean and await pickup.)
Re: (Score:2)
They also could float, but only for a brief time. A salt plug would dissolve, a chamber would flood, and the canister would sink to the deep ocean floor. Do what you like with your submarines - you aren't going to find a paint-can sized canister in thousands of square miles of deep ocean floor.
Re: (Score:1)
It makes me wonder if the film wasn't designed to "self destruct" if exposed to seawater.
It wouldn't be hard to put something in the canister that if dissoved in water would cause the film to turn to plastic mush or at the least, destroy the information recorded on the film.
Re: (Score:2)
Why old school ? (Score:2)
I think the DoD has finally figured out that the next big war we fight with a real adversary ( China, Russia, etc ) will be an interesting fight indeed.
The very first thing that is going to happen is the destruction or degradation of orbiting assets. This means SIGINT, GPS and optical observation capabilities are going to be rendered useless right out of the starting gate. If your war strategy and / or War Toys rely too heavily upon the use of this technology, it's going to be a very short war I think.
Tea
Re: (Score:2)