Slashdot Mirror
The Emerging Science of DNA Cryptography
KentuckyFC writes "Since the mid 90s, researchers have been using DNA to carry out massively parallel calculations which threaten encryption schemes such as DES. Now one researcher says that if DNA can be used to attack encryption schemes, it can also protect data too. His idea is to exploit the way information is processed inside a cell to encrypt it. The information that DNA holds is processed in two stages in a cell. In the first stage, called transcription, a DNA segment that constitutes a gene is converted into messenger RNA (mRNA) which floats out of the nucleus and into the body of the cell. Crucially, this happens only after the noncoding parts of the gene have been removed and the remaining sequences spliced back together." (More below.)
KentuckyFC continues: "In the second stage, called translation, molecular computers called ribosomes read the information that mRNA carries and use it to assemble amino acids into proteins. The key point is that this is a one way process. Information can be transferred from the DNA to the protein but not back again because during the process various details are lost, such as the places where the noncoding sequences have been removed. The new idea behind DNA cryptography is to exploit this to encrypt a message. The message is encoded in the sequence of bases in the DNA (A for 00, C for 01, G for 10, T for 11, for example) and then processed. The resulting protein is then made public. The key, which is kept private, is the information necessary to reassemble the DNA from the protein, such as the position of the noncoding regions (abstract)."
It's still organic computing. We've already demonstrated that there are some classes of computational problems that are massively parallel and can benefit from the use of organic instead of synthetic design. This is decades-old news. The problem is doing this on a mass and automated scale, and then figuring out how to reintegrate these systems into the digital ones we use now. Digital systems are very fast, but lack capacity. Organic systems are very slow, but have incredible capacity. What's needed is a bridge between these two developing systems. The good news is... Research on organic computing has been very slow... people are far more interested in silicon right now, so there's no real rush.
#fuckbeta #iamslashdot #dicemustdie
This sounds amazingly,stupidly brittle. When it comes down to it, it looks like some variant of a substitution cypher. Now I'm not a cryptographer, but I'm pretty sure blowing this thing out of the water would be a good exercise for a grad-school Crypto class.
Test your net with Netalyzr
Couple notes for people who haven't read the paper:
1. Their scheme is not in-vivo (they're not actually working with DNA and proteins). It's a computational process that is based on the information transformations that occur inside a cell.
2. It's kind of cute and nifty, but not particularly applicable. They discuss weaknesses in the attack, but in a pretty handwavey way. The core problem is that their "encrypted text" will include their entire plain text, just split up into pieces. Secondly, it doesn't seem to offer anything particularly new when compared to traditional block ciphers.
3. Mathematically, this has nothing to do with biology. It's just loosely based on biological processes, and it's not really clear that these biological processes have anything particular to contribute to development of encryption. Transcription is just a mapping (from genomic DNA to mRNA), and translation is just a lossy mapping (from 3-tuples of mRNA to peptides). Mathematicians and cryptographers have been aware of generalized versions of these functions these for a long time (homomorphisms and reverse homomorphisms). There's not much new being introduced here.
-Laxitive
At least that of those who run the secure system.
Seriously. Nowadays it's far easier to just do a little social engineering (partially scripted) than to try to break any encryption scheme. Even the highest security company has some stupid grunts and drones.
They should fix the weakest link in the chain first.
I learned something important, when I programmed my first GUI program for a large client: If they can do something wrong, they *will*.
The only solution, is to not give them any functionality that they could mis-use. Build your UI and your backend API like a deep packet inspecting firewall.
Then, when that works, start to think about other ways to strengthen it.
Any sufficiently advanced intelligence is indistinguishable from stupidity.