- cypherpunks - lists.cpunks.org

[drone-list] GAO Reports
by Al Mac Wow 25 Oct '13

25 Oct '13

The GAO has a constant stream of reports, which got disrupted by the government shut down. Here are some recent releases whose titles sound like they may have something to do with drones. Defense Acquisitions: Navy Strategy for Unmanned Carrier-Based Aircraft System Defers Key Oversight Mechanisms, GAO-13-833, September 26 http://www.gao.gov/products/GAO-13-833 I know that the US Navy has been testing various kinds of autonomous drones, which can land and take off from Aircraft Carriers, without a human in the loop. I do not know how they avoid colliding with all the manned aircraft doing the same thing. GAO found that in fiscal year 2014, the Navy plans to commit to investing an estimated $3.7 billion to develop, build, and field from 6 to 24 aircraft as an initial increment of Unmanned Carrier-Launched Airborne Surveillance and Strike (UCLASS) capability. This is more than I knew before, and that is a staggering sum of money, but it is not clear from GAO summary, if they talking about autonomous or not. Further, the GAO is not happy with the state of oversight or accountability, has some advice for Congress and the Secretary of Defense. From the summary: This report (1) assesses the UCLASS acquisition strategy, (2) identifies key areas of risk facing the system, and (3) notes areas where the Navy's strategy contains good practices. To do this work, GAO reviewed the Navy's acquisition strategy and compared it to DOD's acquisition policy, among other criteria; and reviewed Navy acquisition documents and spoke with Navy and Office of the Secretary of Defense officials. I downloaded a copy of the full report, to review later. Here is its link: http://www.gao.gov/assets/660/658236.pdf I named my copy: GAO Drones Military USN UCLASS 2013 Sept. It is 1.2 Meg size, with 26 pages. Defense Headquarters: DOD Needs to Reassess Options for Permanent Location of U.S. Africa Command, GAO-13-646, September 9 http://www.gao.gov/products/GAO-13-646 I know that there are a lot of drone operations, many places, including Africa. I glanced at the summary. It does not sound like this report involves drones. Basically, AFRICOM HQ is in Germany because DoD asserts thats cheaper than in the USA, but GAO is not convinced that exporting over 4,000 jobs is in the USAs best interests. Global Positioning System: A Comprehensive Assessment of Potential Options and Related Costs is Needed, GAO-13-729, September 9 http://www.gao.gov/products/GAO-13-729 I know that many drones navigate by GPS which can be hacked. If I am reading the summary correctly, ½ of current USAF budget is eaten by outer space growth in GPS satellites from 24 to 30. GAO says USAF cost analysis is a good start, but more is needed. National Airspace System: Improved Budgeting Could Help FAA Better Determine Future Operations and Maintenance Priorities, GAO-13-693, August 22 http://www.gao.gov/products/GAO-13-693 I know that FAA has deadlines to approve dramatic increase of drones in NAS. I suspect the sequester and other federal budget issues may have impacted that work. This is about ATC Nex Gen, which is a plan to replace ground based Air Traffic Control with some GPS variant. I can see many things which could go wrong, off-topic here, more suitable for RISKS. I have heard NOTHING about Nex Gen impact on drone operations. I suspect the portions of the gov focused on drones, and on Nex Gen, do not talk to each other. GAO is concerned about ATC overworked from current operations, before drones added to the picture, and main reason ATC capacity problem is facilities falling apart from old age to such a degree that it is unsafe to send humans in to fix them. If you are interested, I can forward off-list. I also have links to scores of other GAO reports recently released, on topics of: * Homeland Security * Military * Foreign Aid * Food safety * Federal finances * Economy * Education * IRS * Post Office * A list of private companies with GAO investigations I dont recognize any as drone manufacturers, but I dont have the complete list in my head. * And other topics In my prior downloading of GAO reports, I have learned that GAO reports are works of the U.S. government, not subject to copyright protection in the United States. They may be reproduced and distributed in their entirety without further permission from GAO.[1] However, because these works may contain copyrighted images or other material, permission from the copyright holder may be necessary if you wish to reproduce any of the content separately. I previously downloaded: * 4 other GAO reports on Drone Military topics + 1 more today. * 2 on Drones worldwide (all nations) * 5 on Drones in NAS (domestic) Al Mac = Alister William Macintyre _____ [1] Thus it would be Ok for me to upload to Scribd and other places. But before I share with lots people, I want to study them myself. -- Want to unsubscribe? Want to receive a weekly digest instead of daily emails? Change your preferences: https://mailman.stanford.edu/mailman/listinfo/drone-list or email companys(a)stanford.edu

1 0

[cryptography] Fwd: GB Secure Messenger V 06 released
by R.R. D. 25 Oct '13

25 Oct '13

fwd fyi ---------- Forwarded message ---------- Subject: GoldBug Secure Messenger V 06 released GoldBug - Secure Instant Messenger / V 0.6.2088 released. http://goldbug.sf.net https://sourceforge.net/projects/goldbug/ Download: https://sourceforge.net/projects/goldbug/files/goldbug-im_0.6._RELEASE/ Encryption Model: (SSL -> (AES -> (RSA -> (Message)))) GoldBug is a secure Instant Messenger. You can be sure with using GoldBug (GB), that no third party can look into your chat communication. Private user-to-user communication remains private. GoldBug therefore uses strong multi-encryption with different layers of modern encryption technologies of well known and revised crypto libraries (like libgcrypt (GnuPG) and OpenSSL). The app offers as well decentral and encrypted Email and decentral public E*IRC-Chat. GB is a Desktop / Mobile GUI Interface based on libspoton: http://spot-on.sf.net New Features and Improvements: (1) Introduction of ElGamal encryption key pairs (as alternative to RSA-Keys). (2) Signature key pairs are extended to a choice of: DSA and RSA. (3) Added Accounts for chat-servers/neighbors-connections: Create a dedicated connection on your EMPP-Chat-Server for friends only with a password. (4) Added pop-up windows per 1:1-friend-chat (doubleclick on a friend to open it). (5) Allow neighbors to be defined such that (non-ssl)-plaintext connections are prohibited (HTTPS-Only-Connections, Default: enabled - For that reason, please remove neighbors.db. in case you overtake your ".spoton"-datapath). (6) Introduced threaded peers: Go parallel with your processes! (7) Added Magnet-Uri Scheme for e*IRC/Buzz-Chat Channels as kind of Booksmarks for your echoed IRC-like-Chatrooms! _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography

2 1

Re: [pfSense] Hardware requirements for gigabit wirespead
by Chris Bagnall 24 Oct '13

24 Oct '13

On 24/10/13 7:31 pm, Adam Thompson wrote: > If I upgraded to a better-quality unit, or switched to licensed > spectrum, I could probably eliminate the variability and increase speed > simultaneously. Indeed, we have Ubiquiti kit running point to point links in the 5Ghz unlicensed spectrum (band C) over around 18km which deliver ~65Mbps throughput. I think our distance record is just shy of 68km. > Within the Ubiquity line, the AirFiber apparently would get me to > ~99.99% reliability at ~600Mbps, or ~99.9% reliability at ~1Gbps. Still > using unlicensed spectrum, using the built-in directional antennas. Do check the 24Ghz spectrum rules carefully in your jurisdiction - certainly here in the UK the 24Ghz unlicensed spectrum is limited, and only allows fairly low power without a licence. > I do not have personal > experience with Alvarion, but I can unreservedly recommend Dragonwave. I'd add Motorola Orthogon kit to that list, based on some offshore experience with it a few years ago. Kind regards, Chris -- This email is made from 100% recycled electrons _______________________________________________ List mailing list List(a)lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list

1 0

CryptoSeal shutters, ala: LavaBit
by grarpamp 24 Oct '13

24 Oct '13

Voluntary shutdown beforehand... https://privacy.cryptoseal.com/ http://cryptoseal.com/team/ https://news.ycombinator.com/item?id=6585649 http://arstechnica.com/information-technology/2013/10/cryptoseal-vpn-shuts-… http://it.slashdot.org/story/13/10/21/2157225/cryptoseal-shuts-down-consume…

13 27

"How I compiled TrueCrypt 7.1a for Win32 and matched the official binaries"
by staticsafe 24 Oct '13

24 Oct '13

https://madiba.encs.concordia.ca/~x_decarn/truecrypt-binaries-analysis/ -- staticsafe O< ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post. It is not logical. Please don't CC me! I'm subscribed to whatever list I just posted on.

1 0

Mail Lists In the Post-Snowden Era
by grarpamp 24 Oct '13

24 Oct '13

Regarding the subthread about examining sources... http://ask.slashdot.org/story/13/10/22/1416201/ask-slashdot-can-bruce-schne…

1 0

Legality of warrantless tech trolling
by grarpamp 24 Oct '13

24 Oct '13

And will these sorts of rulings be used to support cases brought to stop the recently disclosed spy programs... http://www.wired.com/threatlevel/2013/10/warrant-required-gps-trackers/

1 0

Re: Undernet IPv6 Interop [was: Enigmabox/cjdns]
by Eugen Leitl 24 Oct '13

24 Oct '13

Forwarded with permission. ----- Forwarded message from Caleb James DeLisle <cjd(a)hyperboria.ca> ----- I'm not really worried about what the IETF has to say, at some point I'll probably add an option to use IPv4 for cjdns too. When you do a DNS lookup for a site it will allocate an address for that machine out of whatever block you choose. Applications won't even have to support IPv6 to support cjdns. As far as address generation speed, the address is a double-sha-512 of your public key so it's extremely fast. Anything less than 128 bits (you're forced to collide the last 8 bits) would be dangerous. I'm sure we could have decided to limit valid keys to a fixed 16 bits or maybe even 24 but 48 bits would be quite unreasonable to expect of small devices. ----- End forwarded message -----

2 1

Re: [serval-project-dev] More on mesh addressing.
by Paul Gardner-Stephen 24 Oct '13

24 Oct '13

Hello, Jeremy I think has answered the broadcast issue, so I will focus more on the entropy issue. On Thu, Oct 24, 2013 at 3:48 PM, Miles <myles(a)tenhand.com> wrote: > > > On Wednesday, October 23, 2013 9:18:36 PM UTC-7, Paul Gardner-Stephen > wrote: >> >> Howdy, >> >>> >>> I think it is better that we harvest a nice lump of entropy from the >> radios rather than install random data (that might give naughty people help >> reproducing your private keys). We could read RSSI levels from the UHF >> radio, hash it a couple of times, and feed some bits into the entropy pool. >> This would just require talking to the radio a bit, which isn't too hard. >> > Using the radio as a HWRNG is interesting. Wouldn't RSSI be easily > predictable (and influenceable) by any observer with an SDR radio? At the > very least you'd need to tune the radio to an unknown channel, bandwidth & > hopping code first. Or use the difference between the two radios in a > clever way. User space clock solutions like havaged or DakaRand seem > easier. > I think clocks are good to use, also. For the radio RSSI, we could easily make an entropy gathering mode where the radio hops over quite a wide band, perhaps from about 870MHz ~ 1000MHz in a random pattern sampling ambient energy levels, i.e. without talking to a remote radio, just listening. Combine that with some clock input, and feeding the RSSI results into the forward channel selection to help further randomise the hopping sequence while sampling for RSSI, and we should be able to make a fairly robust entropy source. Thoughts? Paul. > > >> >>> >>>> I am not sure how easy it would be to detect the address conflicts when >>> they occur (regardless of address range and size). It would probably >>> require some careful thought and work to implement it >>> >>> >> I agree that it is ugly in many ways, short of getting a doctoral student >> to work on the problem for a few years. Even then, we still need a solution >> until then. Let's keep thinking about it for a few days and see if either >> of us can come up with a good solution. >> > IP collisions could be an unintended accident or a deliberate DOS. In the > case of DOS, doing nothing seems better than amplifying/feeding the energy > monster. > > Using the Mac -> IP conversion, we know that any accidental collision will > share our last 3 MAC bytes. But the odds are very good they won't share > bytes 2-3. > RARP/ARP/RARP would be awesome if it didn't fail for hidden/distant/lossy > nodes. > > Nodes with IP address conflicts can still send and receive broadcast > traffic. What is serval already broadcasting that we could use to look for > trouble unicasting? > Broadcast to nearest node's (serval?) echo service, unicast to them, if > the response doesn't come back, re-Ip? > > -- > You received this message because you are subscribed to the Google Groups > "Serval Project Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to serval-project-developers+unsubscribe(a)googlegroups.com. > To post to this group, send email to > serval-project-developers(a)googlegroups.com. > Visit this group at > http://groups.google.com/group/serval-project-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to serval-project-developers+unsubscribe(a)googlegroups.com. To post to this group, send email to serval-project-developers(a)googlegroups.com. Visit this group at http://groups.google.com/group/serval-project-developers. For more options, visit https://groups.google.com/groups/opt_out.

1 0

Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
by Russ Nelson 24 Oct '13

24 Oct '13

Tony Naggs writes: > I think you a overestimating how much real entropy you will collect this > way [ through powerline drift.] Indeed. By the time you set up a powerline interface, you may as well just reverse-bias a diode, compare it to a low-pass-filtered version of itself, and capture that noise. You could do it with a DigiSpark, and get a USB bytestream. 100% open source, 100% auditable. http://digistump.com/ -- --my blog is at http://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

3 2