I saw this a few days in the DARPA SBIR/STTR release. My understanding is that they do not want to use a public blockchain, instead just utilize blockchain technology across DoD servers to make them less susceptible to a attack, while also giving clear transaction logs for certain military requests that have compliance needs.
The private blockchain will give them state machine replication, some kind of method of encrypted authentication, and a platform for transaction verification across military/dod (or whatever the specific use cases are). The communication bit could work as well since they don't have to store the messages themselves in the blockchain. Since the blockchain is private, this also somewhat solves the problem of transaction speed. There would probably be some lag, but probably just a few seconds or even less if optimized.
Something like Ethereum (with whisper and and swarm) could work if they were looking to use a public blockchain, but they specifically reference Hyperledger.org in their publication.
If the source code to this encrypted database were to be released publicly (say by "leakers") what would stop them from accessing and writing to said database (err excuse me, "blockchain")
Network access and presumably some centralized key hierarchy.
Same thing that would prevent some one from writing to the private blockchains banks are setting up for clearinghouse purposes.
If your the security of your cryptographic system is dependent on anything but the secret keys being secret it's time to go back to the drawing board.
Bitcoin works because it uses proof of work as a gating mechanism to prevent abuse, closed blockchains usually rely on other mechanisms as the parties involved in them can negotiate the terms via other means.
I built a totally decentralized and secure P2P/DHT communications platform a long time ago called DeOps - https://github.com/swax/DeOps
It let's members of a group create a totally private darknet with a hierarchy of trust among themselves using a chain of signed trust tokens. All packets are encrypted with the key of the receiver and signed by the sender. It even uses random ports and sends filler traffic between nodes to prevent finger printing.
I built on top of it services like IM, VOIP, chat rooms, a versioned file system, mail, message boards, etc.. I had a lot of free time lol. The nodes automatically manage the storage of data around the DHT.
Why not try to pitch them the flatform? Or maybe even make the requested changes to it so that it fits the spec more closely to show you're serious. Could be good money.
"time to live/self delete for messages" on a "Customized blockchain implementation" seems to be contradictory. Any data deleted from a block will invalidate all blocks made after the deletion.
DARPA appears to be aware of the paradoxes in their request.
>> "
Q2. The criteria for "time to live/self delete for messages" is impossible to achieve with a Blockchain. Is that a problem for this challenge?
A2. [Response Pending]"
Presumably you're not putting the actual messages in the blockchain. You can use it for metadata like encrypted messages or keys, and use it as a trusted clock for TTLs.
The more confusing requirement is that they want instant communications over a blockchain.
But at a higher level, this is a sort of odd set of requirements. "You have to use a blockchain somehow" is a class project requirement, not an actual project deliverable; nobody should care if it actually uses a blockchain and how as long as it satisfies the required security goals, right? It almost sounds like this RFP was written to describe one person's/group's existing product.
What problem do they have that a blockchain solves? The big win for bitcoin is that the consensus blockchain can be chosen without trust. I would think the military wouldn't be worried about manufacturing consensus among untrusted nodes.
I guess if the messages are stored in the blockchain, a device would be able to delete the key and other information needed to access the message, effectively deleting the message from the device, protecting the user of the device from having to answer for the content of the message.
Sounds more like they want Matrix, where you just have a bunch of redundant federated private servers in their own network. Everyone ends up with copies of all room conversation history, and it uses Signal for the encryption.
When mining the block chain, it is possible to have different miners temporarily working on a chain that will later be invalidated because it's not the longest chain. Maybe it would be possible to somehow use that behavior to encode a self delete?
Not necessarily. You wouldn't have to include the data itself in the transaction, just a hashed key. You then just set the data to expire at the requested time.
It's not only true for crypto. In general the base of many inventions is finding a solution that transcends a core contradiction instead of just living with the tradeoff.
public-key crypto as kristofferR pointed out, but it's so common nowadays that people don't realize how weird of a concept it might have been a few decades ago.
Last year I came across a "fair" version of the Socialist Millionaires problem. How can two persons interact with one another to compare their bank statement. If you think about it, you might consider that in any interaction, a party might abort the exchange as soon as he learns the result and would then have an advantage over the other party. But not too long ago cryptography found a way to make this fair :) (https://www.cryptologie.net/article/279/how-to-fairly-compar...)
However, this sounds like wishing to violate the known laws of physics (specifically, their time invariance). Unless some of the information available at the time T is unavailable at some time T'>T, how could you delete something already shared with another party?
Yeah, HDCP (high-definition copy protection) makes an attempt to make content viewable, but not copyable, but it only works by certifying every single piece of the chain and it's still vulnerable to someone using a simple video camera to capture images of the displayed message.
Barring a human-computer interface that conveys messages directly into someone's brain, I don't see this as possible. If you can see it or if you can hear it, then it is copy-able.
I mostly meant the fact that if you can decode a message that you have with a key and algorithm that you have, you can do it later again, with the same result. Of course, HDCP is an also example of this, since you still have the message and you still have the key, even after some time (as long as you still have both).
Bitcoin solved the double-spending problem with its revolutionary blockchain tech.
Before Bitcoin came along a working decentralized P2P currency had been considered impossible, since nobody could figure out a way to make a P2P currency unforgeable (and therefore work as a currency) before that.
Neat. I doubt I'm DARPA material, but I've been working on a side project that shares a lot of these goals.
I'm implementing a DHT based on Mainline (Bittorrent) to serve as a p2p transport layer for sending asynchronous messages. Then, I want to use the Signal protocol on top of it.
Doesn't meet all of the requirements, but the Cypherpunks-era "darknet" - PGP + Usenet - is a lot closer than a lot of current tools, particularly in terms of deniability.
Most current tools have made some trade-offs to make them more user friendly so they'll actually be used. A perfectly secure messenger isn't very useful if it's so hard to use that no one does.
> Frederic Jacobs, an independent security researcher who has worked as a developer for the encryption messaging app Signal
I thought he worked for Apple now? [0]
EDIT: nevermind, I stand corrected... To make this comment non-useless, let me add to the discussion by saying that the linked DoD website is very cool. Has anyone here applied for a grant via this website (or the underlying DoD protocols)? It seems very foreign and convoluted to me, I'm wondering what the application process is like.
You're right, Fred doesn't work at Open Whisper Systems. He's a student at EPFL, and is doing a summer internship at Apple this year.
Since the article mentions Signal, I think the author just wanted to make it clear that Fred's quotes come with a potential bias since he worked on Signal in the past.
But we're hiring if you want to be quoted in future Motherboard articles on private messaging! =)
I'm glad there's at least one government agency that's competent and technical enough to further our encryption tech. I'm worried the FBI and DOJ will try to spin this DARPA notice into somehow justifying that 'perfect encryption should be a military-only technology'.
I had an idea like this a bit ago, where essentially you would dump your tiny (PGP) message in a giant noise haystack at a random, or generated offset. These messages would get rolled up into a big torrent that gets served every so often.
This is similar to PGP over Usenet, but has the advantage of fooling traffic analysis as well.
It is actually more like dead drops, storing something secret or obfuscated in a very public place, and agents check it only every so often. Since it would just look like a giant torrent, it would be very hard to detect legitimate torrent mirroring from also pulling information out.
Only problem is still the message expiration, which I don't really believe is possible except when using a third party server.
This doesn't scale well and is impossible if you want to send any media. If such an app were to become as popular as iMessage, it would need to handle 200k message per second. I can't download so many messages per second on my phone. You could send blocks with 2000 messages but you could easily be deanonymized (look, out of those 2m messages, he requested 5 blocks with the same author. I think they talk to each other). Don't get my started with kilo to megabyte big images.
If you would not want to scale the app, you could also be deanonymized because you're talking with a niche that has less then 10,000 users.
I wish there was an easy solution to this problem but we already see how badly Bitcoin scale and there are great articles why Bitcoin with its current design can't be used in the real world simply because the block chain has a pretty low limit on transactions per second.
I am currently developing a decentralized messenger that might fit this description. I've developed Ensichat [1] as a messenger that works over Bluetooth and Internet, by sending messages peer to peer. At the moment, I'm adding additional functionality to this app as part of my Bachelor thesis (improved routing, and relays that hold messages while the destination is not reachable).
Does anyone have experience with DARPA projects, and if individuals can apply for it? (I'm not from the US)
Edit: My app does not use a blockchain because the data, bandwidth and power usage aren't an option for mobile devices.
The very concept of a "perfect encryption app" seems flawed to me. Maybe it's just my ignorance talking, but the more important the information you're trying to encrypt, the more of an active and constant process it is to protect it over the long term.
In this case, a "perfect app" would probably be a dedicated department of human beings overseeing the ongoing development and proactive defense of whatever encryption scheme they settle on.
What DARPA apparently wants is a way to hide messages in a broadcast medium. USENET alt binary groups, PornHub, and Twitter would be suitable. It should be something that gets through the Great Firewall of China, probably.
If common image formats get through, then yes, there is a network broadcast format that you can use to securely communicate through the great firewall.
I think the server "wall concept" is easy, the client or ease of use is the real problem. it's not hard to keep encrypting until everything is "ttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt" that for example could be hi to one person and goodbye to another even though they are all the same letter, the problem is always in keys or the need for them/transferring.
Closest they're gonna get to self-destructing messages on a blockchain is trusting the recipient to delete the decryption key after a certain amount of time, along with pruning expired messages from the chain (not perfect, probably good enough).
To their merit, blockchain based messaging is an easy way to prevent a great deal of traffic analysis.
Many people held in high regard by HN for "encryption apps" received DARPA grants for similar work (through CFT). For example, moxie [0].
DARPA does good work and I'm sure they are very interested in having a bullet proof secure messaging system for battlefields and tons of other applications as well. The software quality delivered by defense contractors and the like is much much lower than something like signal, so it's probably a huge need.
I don't think that changes the reality that they're part of a government that's increasingly ham-fisted in its attempts to remove even the veneer of privacy from its citizens. One can accept that DARPA does good work, and also accept that it works for bad people.
The government is not one entity... DARPA's aligned with the military/battlefield technology, unlike the NSA's vague sigint focus. Heads would roll if there was any kind of backdoor here, because it puts soldier's lives at risk with no justification.
Government is not a monolith and different branches often have competing goals.
It makes total sense that the military would prioritize developing and maintaining ways of keeping their communications secure (favoring strong encryption) while intelligence sees the wide availability of SIGINT as essential to their mission (thus favoring weak encryption).
The private blockchain will give them state machine replication, some kind of method of encrypted authentication, and a platform for transaction verification across military/dod (or whatever the specific use cases are). The communication bit could work as well since they don't have to store the messages themselves in the blockchain. Since the blockchain is private, this also somewhat solves the problem of transaction speed. There would probably be some lag, but probably just a few seconds or even less if optimized.
Something like Ethereum (with whisper and and swarm) could work if they were looking to use a public blockchain, but they specifically reference Hyperledger.org in their publication.