> Employing homomorphic encryption techniques, PIR enables datasets to remain resident in their native locations while giving the ability to query the datasets with sensitive terms.
I can imagine a few scenarios there. One perhaps is when db admin should not find out what someone, possibly working on a classified project is querying.
Or say one compartment / project collected the data and now they want to share it with another project. Those read into the second project don't want to reveal to the first one what they are querying because it would reveal classified information.
Another scenario is a database which has results of possibly illegally intercepted communications. If the NSA can argue that the Constitutionally defined "search" doesn't occur until someone actually performs a search (as in runs an SQL query over the data). Then having PIR capability means being able to break the law but only let as few people as possible do it.
Also https://github.com/redhawksdr is pretty damn impressive. It looks like a complete parallel implementation of GNU Radio. Completed with an IDE and such. Wonder how it compares?
This is pretty common in the commercial world too, and something I've done more than once myself. The obvious use case is storing medical records.
In the UK personal medical records are often stored by systems integrators in datacentres with nebulous locations, and need to be accessed by third parties for things like underwriting life insurance policies.
To protect the data (compliance with the EU data protection act) it's encrypted in transit AND at rest. Access to data by third parties is managed through AMRAs (access medical record authorisation), which are completed by the third party, authorised by the data owner (private individual) and given to the data owner's general/dental practitioner or pharmacist, who is able to access and decrypt and appropriately share the sensitive data.
All valid points, but I think it has more to do with this research being popular in the encryption community. One of the Coursera teachers was working on something like that.
An example of use is video games that help prevent hacking and modification.
I think that there could be some great consumer usage for having the ability to encrypt data, but still be able to search it.
I guess an example might be that the NSA has access to other partners information (e.g non-five eyes like Germany) and doesn't want their DB folks to be able to see that they are quering against the databases (e.g Merkels phone number)
Intriguing indeed. Could this tech also be used to query a database or service to plot a route (say for navigating with your car) without revealing the route?
That's nice to see the NSA is contributing to the OSS community. I just randomly picked one of the NSA GitHub repositories, analysed it with VersionEye (https://www.versioneye.com) and found already 25 security vulnerabilities. Who is the best person to contact in this case? Here is the security report: https://www.versioneye.com/user/projects/59479cd06725bd00123....
Can someone explain how some of projects can be MIT-licensed (or anything-else-licensed) as they claim? Aren't they necessarily in the public domain given that they're works of the U.S. Government?
Certain government agencies and subsidiaries are exempt from having their work considered "government work" and can thus claim copyright if they want. I'm guessing the NSA is such and agency. Also if the work was actually done by a contractor then there are other exemptions.
I'd be very interested in more public cryptanalysis of this. It's a damn simple cipher to implement, and if it were at least as secure as say Salsa20/12 it'd be very nice for all kinds of applications.
Does the fact that many of these havent been updated in months or years mean that these are really old projects that effectively hold no value to the NSA and arent close to any of their core operations?
For every one of these projects someone spent a considerable effort do the paperwork to get it pushed out, have it signed off as sanitized, non-embarassing, etc. It is a lot of work to get that done in bureaucratic and risk-averse organisations.
If there had been a community contributing back I expect that there would have been more activity, but if it seems like noone will, would you spend your time pushing out regular updates?
Or they've received updates that make them too important to release? But likely it's just that they haven't had any major updates, and NSA internal bugfixes aren't important enough to push out, or aren't given out due to worries that that would be a national security issue somehow
Also interesting is splitting the repos: that the NSA and IAD have different repos, and that one seems focused on defensive tech while the other is publishing analysis tools.
I know there's a lot of people who aren't fans of the NSA (or what they do), but I think most of us can see a need for a military-grade organization to research defensive technologies for helping secure our infrastructure. I don't think many of us would be unhappy with the NSA if that's all they did. (Or phrased another way: most of us are unhappy because of how they conduct intel work or compromise defensive capability for offensive ones, eg, that whole business with ECC.)
So I think it's important to respond positively to things like the IAD github page, even if we're not fans in general.
I think you're right. It's sad to see many people are looking at these tools and performing a sort of "Allegory of the Cave" by extrapolating, then, the evils that can be done with these tools.
Something, mostly common sense, tells me that we will not find some smoking gun to a crime here in these OSS repos...if anyone wanted that, they can refer to any number of leaks.
Ultimately, I'm happy to see this stuff shared, happy to see others use it and happy to see the OSS community build on it.
"military-grade" doesn't mean anything in the context of crypto. We all use "military-grade" crypto every day. If your argument is that somehow the armed forces are better at computer security than the rest of us, because "military", then I reject it wholeheartedly.
They are criminals and should be disbanded. The US intel community is full of cheats and liars, straight to the top.
I wonder why https://www.iad.gov (linked at https://github.com/iadgov) is not using a TLS certificate trusted in normal browsers. I cannot visit the webpage as it uses DoD Root CA, which is not installed on my computer.
I suspect there are a lot of very incredible computer programmers at the NSA and they're probably using just regular open source non security related tools every day. It's good to see that they're contributing back to the OS community what they can.
Femto (https://github.com/femto-dev/femto) looks pretty interesting to me just based on some work I've needed to do in the past that it would've come in handy for.
It looks like the last commit was over a year ago, though. Is there information I'm not seeing of whether these projects are actively maintained (or still in use at NSA?).
This is nice. It should all be about protecting electronic systems. To help individuals and companies build resilient systems. It protects the USA and the world economy as a whole. It should never be about spying people or even catching criminals IMHO.
Fun sidenote: I was the very first civilian to contribute to their GitHub project back in July 2015, when SIMP was the only project they had up on GitHub.
It was literally a one letter change in the README file, but I still have the privilege to call myself the very first civilian to contribute to the NSA's open source project: https://github.com/NationalSecurityAgency/SIMP/pull/1
[+] [-] rdtsc|8 years ago|reply
> https://github.com/apache/incubator-pirk
> Employing homomorphic encryption techniques, PIR enables datasets to remain resident in their native locations while giving the ability to query the datasets with sensitive terms.
I can imagine a few scenarios there. One perhaps is when db admin should not find out what someone, possibly working on a classified project is querying.
Or say one compartment / project collected the data and now they want to share it with another project. Those read into the second project don't want to reveal to the first one what they are querying because it would reveal classified information.
Another scenario is a database which has results of possibly illegally intercepted communications. If the NSA can argue that the Constitutionally defined "search" doesn't occur until someone actually performs a search (as in runs an SQL query over the data). Then having PIR capability means being able to break the law but only let as few people as possible do it.
Also https://github.com/redhawksdr is pretty damn impressive. It looks like a complete parallel implementation of GNU Radio. Completed with an IDE and such. Wonder how it compares?
[+] [-] Spearchucker|8 years ago|reply
In the UK personal medical records are often stored by systems integrators in datacentres with nebulous locations, and need to be accessed by third parties for things like underwriting life insurance policies.
To protect the data (compliance with the EU data protection act) it's encrypted in transit AND at rest. Access to data by third parties is managed through AMRAs (access medical record authorisation), which are completed by the third party, authorised by the data owner (private individual) and given to the data owner's general/dental practitioner or pharmacist, who is able to access and decrypt and appropriately share the sensitive data.
[+] [-] jamra|8 years ago|reply
An example of use is video games that help prevent hacking and modification.
I think that there could be some great consumer usage for having the ability to encrypt data, but still be able to search it.
[+] [-] zitterbewegung|8 years ago|reply
[+] [-] secfirstmd|8 years ago|reply
[+] [-] Tepix|8 years ago|reply
[+] [-] hueving|8 years ago|reply
:)
[+] [-] libeclipse|8 years ago|reply
[+] [-] reiz|8 years ago|reply
[+] [-] 0xADADA|8 years ago|reply
> The government benefits from the open source community’s enhancements to the technology.
They're hoping that by putting this code out there, unwitting dupes will then collaborate with them to contribute to the surveillance state.
[+] [-] wfunction|8 years ago|reply
[+] [-] dagw|8 years ago|reply
[+] [-] lsh|8 years ago|reply
[+] [-] Toast_|8 years ago|reply
[+] [-] StreamBright|8 years ago|reply
[+] [-] Laforet|8 years ago|reply
[+] [-] voltagex_|8 years ago|reply
[+] [-] marcosdumay|8 years ago|reply
Yes, it's understandable, but still ironic.
[+] [-] killjoywashere|8 years ago|reply
[+] [-] Cryptoholic|8 years ago|reply
SELinux
Accumulo (a popular NoSQL distributed key-value store)
Apache NiFi (data processing system)
etc.
[+] [-] microwavecamera|8 years ago|reply
[+] [-] alltakendamned|8 years ago|reply
[+] [-] api|8 years ago|reply
https://en.wikipedia.org/wiki/Speck_(cipher)
I'd be very interested in more public cryptanalysis of this. It's a damn simple cipher to implement, and if it were at least as secure as say Salsa20/12 it'd be very nice for all kinds of applications.
[+] [-] nautilus12|8 years ago|reply
[+] [-] angry_octet|8 years ago|reply
If there had been a community contributing back I expect that there would have been more activity, but if it seems like noone will, would you spend your time pushing out regular updates?
[+] [-] kingbirdy|8 years ago|reply
[+] [-] SomeStupidPoint|8 years ago|reply
Also interesting is splitting the repos: that the NSA and IAD have different repos, and that one seems focused on defensive tech while the other is publishing analysis tools.
I know there's a lot of people who aren't fans of the NSA (or what they do), but I think most of us can see a need for a military-grade organization to research defensive technologies for helping secure our infrastructure. I don't think many of us would be unhappy with the NSA if that's all they did. (Or phrased another way: most of us are unhappy because of how they conduct intel work or compromise defensive capability for offensive ones, eg, that whole business with ECC.)
So I think it's important to respond positively to things like the IAD github page, even if we're not fans in general.
[+] [-] jamesfe|8 years ago|reply
Something, mostly common sense, tells me that we will not find some smoking gun to a crime here in these OSS repos...if anyone wanted that, they can refer to any number of leaks.
Ultimately, I'm happy to see this stuff shared, happy to see others use it and happy to see the OSS community build on it.
[+] [-] sneak|8 years ago|reply
They are criminals and should be disbanded. The US intel community is full of cheats and liars, straight to the top.
http://www.hasjamesclapperbeenindictedyet.com
[+] [-] alpb|8 years ago|reply
[+] [-] ArneBab|8 years ago|reply
[+] [-] blazespin|8 years ago|reply
[+] [-] sneak|8 years ago|reply
https://www-androidauthority-com.cdn.ampproject.org/i/www.an...
[+] [-] bigon|8 years ago|reply
[+] [-] Cakez0r|8 years ago|reply
[+] [-] deepnotderp|8 years ago|reply
[+] [-] Animats|8 years ago|reply
[+] [-] mtgx|8 years ago|reply
https://sourcecode.cio.gov/
[+] [-] miclill_kit|8 years ago|reply
[+] [-] headmelted|8 years ago|reply
It looks like the last commit was over a year ago, though. Is there information I'm not seeing of whether these projects are actively maintained (or still in use at NSA?).
[+] [-] nautilus12|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] corpMaverick|8 years ago|reply
[+] [-] thrillgore|8 years ago|reply
[+] [-] aramas|8 years ago|reply
[+] [-] pvorb|8 years ago|reply
[+] [-] r3bl|8 years ago|reply
It was literally a one letter change in the README file, but I still have the privilege to call myself the very first civilian to contribute to the NSA's open source project: https://github.com/NationalSecurityAgency/SIMP/pull/1
[+] [-] jameskegel|8 years ago|reply
[+] [-] 0xADADA|8 years ago|reply
[deleted]
[+] [-] Allower|8 years ago|reply
[deleted]