"no one knows how it works" - That caught my attention, having seen computer evolved ASTs. Probably no one knows because no one has put effort to reverse engineer the internals - most of which would be unnecessary complexity that is very likely with neural nets.
Many years back, I had once experimented with PyEvolve to develop a custom trading strategy which was kind-of code with a custom instruction set. The output of a strategy was a string (program AST) that was uglier than most obfuscation outputs with many unnecessary statements. For example "a=1;b=2;c=a+b;d=c/3;if(d==1).." - expand that to many more variables. The program evolved strategies that made small profit and therefore the output was worth analysing. But decompiling that output used to take me hours - and few of those were tweaks of well documented strategies. Others I never understood because it was too much effort for a relatively small profit (and other trading parameters).
Could you not automate that too? Have another stage of evolution where you just randomly delete statements from the 'code' and the fitness function is that the performance doesn't get worse.
This should eventually reduce the 'code' to it's minimal state, removing any unnecessary parts.
I get the sense that many commenters misinterpreted the point of this study. This isn't about show-boating some newfound, great cryptography method, this is about teaching computers to re-write their own code.
If you can write software that improved itself better over time, our species as a whole would advance at incredible speeds. Think about all the possibilities that could evolve from self-maintained programs. Obviously the thought is a bit scary, but it's also incredibly exciting!
Please don't editorialize. Finding the best parameters that optimize an objective function can hardly be called "re-writing its own code." Granted, the article is just as guilty. (Edit: The article also doesn't mention self-modifying code so I'm not sure where you're getting that idea from.)
The technique is an off-the-shelf GAN that attempts to learn a transformation (not arbitrary code!) from input to encrypted output. The learned model is not Turing complete, and most importantly, is _not_ self-modifying. The optimization procedure is what modifies the network, not the network itself.
GANs have been used before to create realistic pictures. They're not new here -- the application is. It's a cool application, sure, but doesn't involve self-modifying code.
If you read the paper, it is not rewriting its own code. It is optimizing for some objective function, which has been done before. For example, the MetroHash family of hash functions were created using a very similar technique back in 2012; the code didn't just learn to create hash functions, the ones it produced were objectively superior to the state-of-the-art at the time. I've applied the same approach to other computer algorithm optimization problems as well.
This technique generalizes poorly, it really only works for algorithms with specific, somewhat narrow characteristics. If you understand the process as a weak form of algorithmic induction then the practical limitations become more apparent. Most code cannot be usefully constructed this way.
> Think about all the possibilities that could evolve from self-maintained programs.
What are some that you are considering? Most maintenance I do is in the form of bug repair and change requests. Most of those wouldn't be fixable (or even identifiable) by machines. It's not errors like "value x should be y" (almost all of those get shaken out in alpha.) It's requests like "When I get to step H in our workflow, I shouldn't have to fill out form 2 to get information about the customer I'm helping."
I mean, for technical things like encryption, I could see a lot of growth potential. Other algorithms where there is a good metric for "better" would also be candidates (compression also springs to mind.) But on the whole, most applications have a lot of human interfacing and critical thinking that needs to happen. AI is going to take a long time to get to the point where it can fix those kinds of problems.
This seems pretty click-baity to me. Especially "no one knows how it works."
Alice generates ciphertext based on plain text and key. Bob generates plaintext based on ciphertext and key. Eve generates plaintext based on only ciphertext. Train the three networks across a variety of plaintetxts,
No doubt it's cool, but I would be very surprised if it offered any insight into, or represented an advance for strong cryptography.
The paper [1] is by Abadi [2], which is a pretty big name in crypto. So I can assume it's something with value, wether the press can or can't convey that is another story.
I might be reading your comment incorrectly, but it sounds like you're interpreting that phrase to mean that no one knows how training the neural network works.
I think, instead, it's in reference to the resulting function not having been analyzed. From the article:
The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob...
There's nothing clickbait about it. No one knows how the cryptographic algorithm it invented works. It's very, very difficult, perhaps impossible, to reverse engineer neural networks. They also don't claim it's an advance for strong cryptography, it's just interesting experiment with NNs.
I completely agree. Also, they may not know but because they haven't made a detailed analysis, it's not like they couldn't know even if they wanted to. So yeah, click-bait.
At this point in time, when I hear 'no one knows/understands the process' or some variation relating to neural networks or deep learning, I know their maturity on the subject.
This is most probably a rather lousy hack put together by Alice and Bob, but it maps out a very interesting future were we one day maybe can stop worrying about how our algorithms work and make that the job of the computer.
It also is totally terrifying to live in a world were computers can hide their messages from their own creators.
It doesn't. As an AI developer you have access to the AI code and memory.. How could you not replay the encryption process used by the AI since you know the state of what it "knows" constantly? Both have a encryption and decryption process that you can reproduce.
Or they can splat you metaphorically or physically because you stepped into a corner case of the neural network that nobody understood, could foresee and didn't make any difference to the 99.99999999% of the other cases. But I guess random strokes of bad luck always happened. They will be delivered in new ways.
TFA's title is a little clickbaity by adding "noone knows how it works" which apparently means that:
The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob, but for one specific training run they observed that it was both key- and plaintext-dependent. "However, it is not simply XOR. In particular, the output values are often floating-point values other than 0 and 1," they said.
Outputting floats instead of discrete values actually sounds like a very exploitable hole to me.
It reminds me of the classic "check if your model corresponds to reality" example where a one-time pad is broken: the standard said "<0.5V volts is OFF" but your machine was outputting 0.1V for OFFs that came from computing 0 xor 0 and 0.2V for OFFs that came from computing 1 xor 1.
I'm not sure what conclusions we're supposed to draw from this. Just because they were able to hide the messages from a 3rd AI doesn't mean the encryption was good. Shouldn't a human examine it and see if they can codebreak it? Isn't the goal better encryption?
Isn't that a bit like "security through obscurity"? Unless I'm misunderstanding something, the cryptographic algorithm that the AI comes up with isn't guaranteed to be based on a provably NP-hard problem, so there aren't any formal guarantees. It would also be very hard to reason about, inspect, and prove correct.
Please note that I'm in no way dissing the researchers' work. What they did is pretty cool, but I can't see an obvious way to use these AI-generated algorithms in production systems where you may need to certify their correctness.
Our chosen network structure is not sufficient to learn general implementations of many of the mathematical
concepts underlying modern asymmetric cryptography, such as integer modular arithmetic.
We therefore believe that the most likely explanation for this successful training run was that Alice
and Bob accidentally obtained some “security by obscurity” (cf. the derivation of asymmetric
schemes from symmetric schemes by obfuscation (Barak et al., 2012)). This belief is somewhat reinforced
by the fact that the training result was fragile: upon further training of Alice and Bob, Eve
was able to decrypt the messages. However, we cannot rule out that the networks trained into some
set of hard-to-invert matrix operations resulting in “public-key-like” behavior. Our results suggest
that this issue deserves more exploration.
>> The cryptographic algorithm that the AI comes up with isn't guaranteed to be based on a provably NP-hard problem, so there aren't any formal guarantees.
There are no cryptographic schemes, either in theory or in practice, that reduce to NP-hard problems. Instead, they rely on different "cryptographic hardness assumption" including factoring (and related number-theoretic problems) and a variety of so-called "lattice" problems. Are these assumptions as sure as P!=NP? No, they are explicitly stronger. Are they better cryptosystems than this work generates? Almost surely.
In you are interested, there are actually some negative results that suggest it would be impossible to do cryptography based on NP-hardness alone. Akavia, Goldreich, Goldwasser, Moshkovitz show this for a restricted class of NP-hard problems in a 2006 paper [http://people.csail.mit.edu/akavia/AGGM.pdf]. More philosophically, there is a big difference between computational hardness and cryptography: in complexity, we study worst-case hardness, but in cryptography, we need breaking a cipher (for example) to be hard with very high probability. Rather surprisingly, there seems to be a big difference between these two goals.
It's not clear from the article whether they train the networks with the same shared-key in every iteration, or if they randomize it. Any info on that?
> While it seems improbable that neural networks would become great at cryptanalysis, they may be quite effective in making sense of metadata and in traffic analysis.
How does that square with the fact that the best cryptanalists appear to have nothing but their own neural networks to work with?
This reminds me of the genetic algorithm that came up with a tone discriminator that at first glance looked like it could not work (parts connected wrong or not at all, and yet, crucial to functioning).
Because humans have invented tools - math, notably - that they can use to be more formal and precise when they deal with problems of this sort. To date, neural networks can't -- they're doing very well at the kind of "intuitive" pattern matching that our brains do, but less well on an algorithmic front. It's one of the really interesting frontiers of AI right now. The folks at DeepMind recently showed, for example, that a variant of their "Neural Turing Machine" architecture could learn to do things involving more like what we think of as discrete algorithms (https://deepmind.com/blog/differentiable-neural-computers/ ), but all of this is very early work.
"The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob, but for one specific training run they observed that it was both key- and plaintext-dependent. "However, it is not simply XOR."
Really interesting that for the first ~6500 steps Eve was better at decrpyting the messages than Bob, which had access to the key.
Would be cool to see a setup like this in which Eve is a cohort of decryption tools, otherwise your Alice network will just overfit against its mechanics. Ie, if Eve uses lockpicks to open a door, an Alice solution would eventually replace the key-lock with a number pad - not necessarily any more secure, but will foil Eve every time.
Isn't this just the automated version of "anybody can invent crypto they can't break themselves"? It doesn't sound like the neural nets were provided with any high level cryptanalytic primitives. Just basic math and left to bodge something together. I can't imagine it would be easy to hill-climb towards an understanding of the why behind crypto. Algorithms that work look a lot like ones that have glaring flaws - but those flaws only glare if you know the right way to come at them.
It must be the time for Cryptography + Machine Learning. I had an O'Reilly Security 2016 talk "Machine Learning to Improve Random Number Generators" accepted this June 2016:
This reminds me of Peter Watts's novel <Blindsight>. Two captured "Scramblers" (the highly intelligent alien without self-consciousness) managed to communicate with each other in a way defying all human analysis, even with human knowing what they are saying (the plain text).
[+] [-] anupshinde|9 years ago|reply
Many years back, I had once experimented with PyEvolve to develop a custom trading strategy which was kind-of code with a custom instruction set. The output of a strategy was a string (program AST) that was uglier than most obfuscation outputs with many unnecessary statements. For example "a=1;b=2;c=a+b;d=c/3;if(d==1).." - expand that to many more variables. The program evolved strategies that made small profit and therefore the output was worth analysing. But decompiling that output used to take me hours - and few of those were tweaks of well documented strategies. Others I never understood because it was too much effort for a relatively small profit (and other trading parameters).
[+] [-] dflock|9 years ago|reply
This should eventually reduce the 'code' to it's minimal state, removing any unnecessary parts.
[+] [-] user5994461|9 years ago|reply
I spent hours reverse engineering one of the custom cryptographic function, it looked like nothing I ever saw... then I realized it was Base64 :D
[+] [-] traviswingo|9 years ago|reply
If you can write software that improved itself better over time, our species as a whole would advance at incredible speeds. Think about all the possibilities that could evolve from self-maintained programs. Obviously the thought is a bit scary, but it's also incredibly exciting!
[+] [-] gcr|9 years ago|reply
For the curious, here is the preprint: https://arxiv.org/pdf/1610.06918v1.pdf
The technique is an off-the-shelf GAN that attempts to learn a transformation (not arbitrary code!) from input to encrypted output. The learned model is not Turing complete, and most importantly, is _not_ self-modifying. The optimization procedure is what modifies the network, not the network itself.
GANs have been used before to create realistic pictures. They're not new here -- the application is. It's a cool application, sure, but doesn't involve self-modifying code.
[+] [-] jandrewrogers|9 years ago|reply
This technique generalizes poorly, it really only works for algorithms with specific, somewhat narrow characteristics. If you understand the process as a weak form of algorithmic induction then the practical limitations become more apparent. Most code cannot be usefully constructed this way.
[+] [-] ctrl-j|9 years ago|reply
What are some that you are considering? Most maintenance I do is in the form of bug repair and change requests. Most of those wouldn't be fixable (or even identifiable) by machines. It's not errors like "value x should be y" (almost all of those get shaken out in alpha.) It's requests like "When I get to step H in our workflow, I shouldn't have to fill out form 2 to get information about the customer I'm helping."
I mean, for technical things like encryption, I could see a lot of growth potential. Other algorithms where there is a good metric for "better" would also be candidates (compression also springs to mind.) But on the whole, most applications have a lot of human interfacing and critical thinking that needs to happen. AI is going to take a long time to get to the point where it can fix those kinds of problems.
[+] [-] ape4|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] FT_intern|9 years ago|reply
[+] [-] JackFr|9 years ago|reply
Alice generates ciphertext based on plain text and key. Bob generates plaintext based on ciphertext and key. Eve generates plaintext based on only ciphertext. Train the three networks across a variety of plaintetxts,
No doubt it's cool, but I would be very surprised if it offered any insight into, or represented an advance for strong cryptography.
[+] [-] ecesena|9 years ago|reply
[1] https://arxiv.org/pdf/1610.06918v1.pdf
[2] https://en.wikipedia.org/wiki/Mart%C3%ADn_Abadi
[+] [-] pohl|9 years ago|reply
I think, instead, it's in reference to the resulting function not having been analyzed. From the article:
The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob...
[+] [-] agumonkey|9 years ago|reply
"In some cases they've been designed by other computers. We don't know exactly how they work."
Timely.
[+] [-] Houshalter|9 years ago|reply
[+] [-] cheez|9 years ago|reply
[+] [-] lesolorzanova|9 years ago|reply
[+] [-] eanzenberg|9 years ago|reply
[+] [-] posterboy|9 years ago|reply
[+] [-] bkin|9 years ago|reply
[deleted]
[+] [-] widforss|9 years ago|reply
It also is totally terrifying to live in a world were computers can hide their messages from their own creators.
[+] [-] n4ss|9 years ago|reply
[+] [-] pmontra|9 years ago|reply
[+] [-] trungaczne|9 years ago|reply
[+] [-] bkin|9 years ago|reply
The researchers didn't perform an exhaustive analysis of the encryption methods devised by Alice and Bob, but for one specific training run they observed that it was both key- and plaintext-dependent. "However, it is not simply XOR. In particular, the output values are often floating-point values other than 0 and 1," they said.
Just saying...
[+] [-] Strilanc|9 years ago|reply
It reminds me of the classic "check if your model corresponds to reality" example where a one-time pad is broken: the standard said "<0.5V volts is OFF" but your machine was outputting 0.1V for OFFs that came from computing 0 xor 0 and 0.2V for OFFs that came from computing 1 xor 1.
[+] [-] Touche|9 years ago|reply
[+] [-] pzh|9 years ago|reply
Please note that I'm in no way dissing the researchers' work. What they did is pretty cool, but I can't see an obvious way to use these AI-generated algorithms in production systems where you may need to certify their correctness.
[+] [-] paradite|9 years ago|reply
[+] [-] benkuykendall|9 years ago|reply
There are no cryptographic schemes, either in theory or in practice, that reduce to NP-hard problems. Instead, they rely on different "cryptographic hardness assumption" including factoring (and related number-theoretic problems) and a variety of so-called "lattice" problems. Are these assumptions as sure as P!=NP? No, they are explicitly stronger. Are they better cryptosystems than this work generates? Almost surely.
In you are interested, there are actually some negative results that suggest it would be impossible to do cryptography based on NP-hardness alone. Akavia, Goldreich, Goldwasser, Moshkovitz show this for a restricted class of NP-hard problems in a 2006 paper [http://people.csail.mit.edu/akavia/AGGM.pdf]. More philosophically, there is a big difference between computational hardness and cryptography: in complexity, we study worst-case hardness, but in cryptography, we need breaking a cipher (for example) to be hard with very high probability. Rather surprisingly, there seems to be a big difference between these two goals.
[+] [-] systemfreund|9 years ago|reply
[+] [-] dgacmu|9 years ago|reply
Happy to answer more questions about it. (I'm one of the authors.)
[+] [-] anotheryou|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] jacquesm|9 years ago|reply
How does that square with the fact that the best cryptanalists appear to have nothing but their own neural networks to work with?
This reminds me of the genetic algorithm that came up with a tone discriminator that at first glance looked like it could not work (parts connected wrong or not at all, and yet, crucial to functioning).
https://www.damninteresting.com/on-the-origin-of-circuits/
[+] [-] dgacmu|9 years ago|reply
[+] [-] adrianN|9 years ago|reply
[+] [-] biot|9 years ago|reply
[+] [-] pmyjavec|9 years ago|reply
[+] [-] dharma1|9 years ago|reply
[+] [-] sly010|9 years ago|reply
I think this says it all.
[+] [-] madenine|9 years ago|reply
Would be cool to see a setup like this in which Eve is a cohort of decryption tools, otherwise your Alice network will just overfit against its mechanics. Ie, if Eve uses lockpicks to open a door, an Alice solution would eventually replace the key-lock with a number pad - not necessarily any more secure, but will foil Eve every time.
[+] [-] timvdalen|9 years ago|reply
This is probably because Alice wasn't good at encrypting yet.
[+] [-] wideem|9 years ago|reply
[+] [-] JulianMorrison|9 years ago|reply
[+] [-] rfreytag|9 years ago|reply
http://conferences.oreilly.com/security/network-data-securit...
EDIT: I thought the reference was relevant but please do critique/comment if you feel I've broken some convention.
[+] [-] ajamesm|9 years ago|reply
[+] [-] fooker|9 years ago|reply
[+] [-] strictnein|9 years ago|reply
[+] [-] akfish|9 years ago|reply