Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Microsoft Encryption Security

Microsoft Creates a Quantum Computer-Proof Version of TLS Encryption Protocol 128

holy_calamity writes: When (or if) quantum computers become practical they will make existing forms of encryption useless. But now researchers at Microsoft say they have made a quantum-proof version of the TLS encryption protocol we could use to keep online data secure in the quantum computing era. It is based on a mathematical problem very difficult for both conventional and quantum computers to crack. That tougher math means data moved about 20 percent slower in comparisons with conventional TLS, but Microsoft says the design could be practical if properly tuned up for use in the real world.
This discussion has been archived. No new comments can be posted.

Microsoft Creates a Quantum Computer-Proof Version of TLS Encryption Protocol

Comments Filter:
  • by XxtraLarGe ( 551297 ) on Monday August 03, 2015 @04:29PM (#50243793) Journal
    Especially if the choice is between your data being secure or not.
    • I bet the NSA is going "FUCK do you know how much these quantum computers cost!?!?"

  • by davidwr ( 791652 ) on Monday August 03, 2015 @04:30PM (#50243813) Homepage Journal

    It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.

    Ah, that would be my federal tax return.

    • It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.

      Ah, that would be my federal tax return.

      Or how to correctly answer your wife/girlfriend when she asks, "Do these jeans make me look fat?"

      • by Anonymous Coward

        It is based on a mathematical problem very difficult for both conventional and quantum computers to crack.

        Ah, that would be my federal tax return.

        Or how to correctly answer your wife/girlfriend when she asks, "Do these jeans make me look fat?"

        I keep telling you. It's your ass making you look fat.

      • by Anonymous Coward

        The question is easy to answer correctly. Or truthfully. Just not both.

        • by bjwest ( 14070 )

          No is both correct and truthful. To answer anymore than that one word, you will have to decide if you want to lie or go back to your ex Rosy.

  • by Anonymous Coward

    TFA doesn't say what they're replacing the integer factorization problem with. Useless.

  • The reason for using math based cyphers is to reduce memory usage. You have a few hundred bytes and can generate the encryption key to encode/decode the message with it. Using math makes your encryption weak to advances in computers and algorithms, where using a one time pad stored in your petabyte file server is possible now, and the NSA would have to hack your computers or break in (for physical access) or control the companies that make your hardware and software to beat that.
    • by Anonymous Coward

      The reason for using math-based ciphers is to reduce key size--not for storage, but for key exchange.

    • OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.

      If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.

      • If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.

        The value of a one-time pad is that if you can get data securely to someone else only during certain time periods, you can exchange your pads at that time then you can exchange data securely whenever you want to (well, until you use up your pad).

        It's really useful when one party, say, a government, is free to "broadcast" the encrypted information, say, over shortwave radio, and the other party, say, a spy, is only a listener. For the spied-upon country to detect the shortwave radio the spy is using will be

      • OTPs are great. On the other hand, you have to use each pad only once. Ever. So to encrypt 1GB of data, you need 1GB of cryptographically random pad. Which you can never use again. And must be a secret with regards to the rest of the world. And must be present on both the sending and receiving end of the communication.

        If I knew how to get 1GB of unique data (be in OTP pad or the real data) from the sender to the receiver in secrecy I wouldn't need encryption in the first place.

        Not quite. You can't repeat the pad the same way ever - that is, you don't want to wrap it or reset to known locations using any kind of protocol. You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap. So you're data limited unless you have an infinite data source.

        That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number

        • You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap

          You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.

          There is literally no security difference between these two pads:

          XOJIGQIOJG
          XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG
          (for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).

          The second one is just far less efficient. You can try to recover the efficiency by saying the next time you use that OTP, you use every ch

          • You can, however, randomly skip around in some manner, as long as you only go forward and do not wrap

            You're just performing anti-compression / encryption on the pad, which was already perfectly encrypted.

            There is literally no security difference between these two pads:

            XOJIGQIOJG XAOAAJAAAIAAAAGAAAAAQAAAAAAIAAAAAAAOAAAAAAAAJAAAAAAAAAG (for every character you have already decoded, you must skip that many characters before reading the next character from the one-time pad).

            There is no requirement to skip a character in one-time pads. You can read sequential bytes without any issue. That said, how you use the one-time pad data can certainly contribute to its worth or worthlessness.

            Supposing that the first example is used as is, and the second example all the A's are skipped, that that's correct - there is no difference. However, there is a big difference if in the second example you don't skip the A's - the pad is degrading your security as it's not sufficiently random.

            That said, you could probably use a synchronized random number generator as the shared pad data.

            That

        • Re:One time pad (Score:5, Interesting)

          by DamnStupidElf ( 649844 ) <Fingolfin@linuxmail.org> on Tuesday August 04, 2015 @12:16AM (#50246399)

          That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.

          That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).

          • That said, you could probably use a synchronized random number generator as the shared pad data. The other side would only be able to decrypt messages for as long as they buffer the random number data; after which the message is lost to everyone for eternity. This could work for a TLS session where messages are exchanged with only a couple minutes (or preferably seconds) delay so that the buffer does not need to be very big.

            That's roughly the definition of a stream cipher (e.g. RC4 or a block cipher in Counter mode). Only a cryptographically secure random number generator works, which is why such a thing is called a stream cipher and not just a "pseudo-random one time pad". In any case it's not a true one time pad because the entropy of the stream of pseudorandom data is limited to the entropy of the internal state of the cipher, and further limited by the entropy of the key. That means stream ciphers can be broken given only the ciphertext, as opposed to using a one time pad. Stream ciphers also share the same weakness as one time pads; reusing the same stream cipher key is just as bad as reusing a one time pad (virtually automatic recovery of all plaintexts encrypted with the same pad/stream).

            There's a big difference:

            With a normal cipher stream (RC4, etc) it's data that is shared on the fly to create the cipher stream in a shared state (TLS, Diffie-Hellman, etc). The fact that you have to create it on the fly leads to vulnerabilities and MITM attacks.

            Conversely with the one-time pad you have all the data pre-shared; in my example of using an RNG (not a PRNG) - it's a synchronized hardware device that is shared. This is why a one-time pad is more secure than any normal cipher stream.

            Howe

        • That said, you could probably use a synchronized random number generator as the shared pad data.

          No; a true OTP is NOT the same as pseudo-random OTP. For an illustration of this concept, let's assume that your adversary knows your algorithm for generating the pads but has no information about the shared secret between you and your partner. To make things easier on your opponent, let's assume that he knows that you plan to encrypt a 1GB plain-text ASCII file.

          In the case of a true OTP, you and your partner must share 1GB of data securely. Because the pad is truly random, any 1GB ciphertext is equally

          • by KGIII ( 973947 )

            I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...

            Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.

            Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say fi

            • I am a math geek. I am not now, nor have I ever been, a crypto-geek. I do have a dumb question...

              Is it possible, and I will try to explain as well as I can, to have an encrypted file that, when decrypted, becomes an actual encrypted file which requires a password to open? I realize that may be a strange way to think about it.

              Let's say that I have a file, a plain text file, and I put it into a password protected .zip file. That new file, the .zip, would then be encrypted, as a whole, into a new file - say file.tar.bz. Now, to open it, you would need to have the shared key PLUS you would need to know the password to the encrypted .zip file.

              I understand that this has nothing to do with TLS and would be wholly impractical for browsing. However, the talk of encryption made me wonder about this and I have been pondering this for a couple of years now. It means it would be something you have and something you know.

              Yes you can encrypt and encrypted file - just as you described. However, you have to use a different crypto keyset to do it or you defeat the encryption by revealing too much information.

              I can think of many ways to share the needed password/pass-phrase securely (for certain definitions of securely). Say, five books in a certain order on a bookshelf and calling with a series of numbers which determine with pages and words are used to make up the pass-phrase. A call could be as simple as, "Number 3, 27, 5, 18, number 7, 14, 32, 8. Confirm?" Which would be book number 5, chapter 3, 27th page, fifth and eighteenth words and book seven, chapter fourteen, thirty second and eighth word would be the password. This does not help if there is someone physically present.

              That was done extensively throughout the Cold War, and is a common use of OTP. It's highly secure, and very difficult to break due to that exact kind of thing.

              Anyhow, there may be some need to change the file type at the recipient's end because decrypting the file.tar.bz file will not necessarily mean that the file has the appropriate .zip extension but, well, that is pretty trivial.

              What am I missing? This, obviously, has absolutely no value in the real world for almost every single person on the planet. I could see it being useful for TLAs or those who are trying to subvert their government (for a variety of reasons which may be good or bad).

              To start, most software detects file types based on the content, not the file names. They may use a file extension as a basic filter, but often that's more of a user-

              • by KGIII ( 973947 )

                Thank you much. Now to find a way to combine a couple of apps and make it do this on its own. It sounds like an enjoyable project. I can, likely, find OSS to include as a way of saving a bunch of time. Basically, my thinking is more for a single person to use it. They can create a file, such as a plain text, encrypt it, take the resulting file and encrypt that into an AES encrypted RAR file that needs a password.

                So, in order to open the file, they will have to know the password for the compressed and encryp

          • No; a true OTP is NOT the same as pseudo-random OTP.

            I said using an RNG not a PRNG.

            A synchronized RNG is generated by synchronizing the clocks on the hardware, and initial seed data. True, it's not a fully random RNG, but it is sufficient for the needs of a OTP crypt/decrypt function as I described.

            I also never said it was perfect; just theorizing on a way that you could do it with shared hardware instead of having to share an enormous file.

            In reality, nobody uses a OTP because if you can securely communicate the length of the pad, you can just as easily communicate the entire message. What is used instead is public-key encryption where your partner can encrypt a message, but only you can decrypt it.

            And yes, OTP has been used to securely communicate many things. In many senses, the Enigma machine is a OTP kind

    • The problem with one-time pads is securely exchanging the key and protecting it between the time of exchange and time of use.

      If I want to open an account with an online bank or shop at an online store with no local brick-and-mortar location, either I have to drive/fly/whatever out to their nearest location or we have to agree on some mutually-trustworthy person to transport the key between us.

      I guess we could agree to transport the key across the Internet, but to do so without weakening security would mean

    • While I have a basic understanding about one-time pads and how they work, I realize that there must be something wrong with this idea but I don't know enough to figure out what.

      There are vast amounts of publicly available documents on the Internet. Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad? In that way avoid the issue of having to transfer the pad between

      • While I have a basic understanding about one-time pads and how they work, I realize that there must be something wrong with this idea but I don't know enough to figure out what.

        There are vast amounts of publicly available documents on the Internet. Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad?

        That isn't a One-Time Pad. In OTP the pad is secret; in the scenario you just described, the content of the "pad" is public. The encryption key is thus not the pad itself, but rather just the identification of the pad ("1st article on Slashdot after noon CST"). Putting aside the fact that an article has relatively low entropy per character, someone with access to just one cyphertext could conceivably test it against a large database of likely public documents and identify the pad simply by looking for a doc

      • The problem is that your OTP needs to be random and text is far from random. A lot of things are known about the data in text, such as the range of possible byte values and the frequency with which different characters are used. These sorts of problems will make your encrypted text extremely vulnerable to statistical analysis.

      • by plover ( 150551 )

        What you've described has been known for centuries as a "book cipher". Benedict Arnold used one during the American Revolutionary War to protect his treasonous communication with England.

        Anyway, there's a really fun way to beat this kind of encryption today. If Mallory can get Alice or Bob to send a copy of BLACK_SQUARE.BMP, it's literally game over. Imagine XORing your key against a bunch of binary zeros. The result is a big patch of the cleartext version of the data that is your key. Google will find

        • by Sulik ( 1849922 )
          Why not just increase the entropy by just using a compressed version of the text, eg: instead of using the text of the first article, zip it, and use that as the pad (removing headers etc). Or use some compressed H.264 youtube videos as the pad (arithmetic coding pretty much guarantees a relatively high entropy).
          • by plover ( 150551 )

            Because then your compression function effectively becomes your encryption function. And it wasn't designed for security.

            Keep in mind these are simple issues to identify and exploit. All these "what-if" scenarios have been played out repeatedly, which is why the standard response is always "use a proven secure algorithm, don't roll your own cryptographic solution." It's easier, less bug prone,and the security has been analyzed by more qualified people than you can afford. Any known weaknesses have already b

      • by dissy ( 172727 )

        Why can't Alice and Bob agree that they will use the text of the first article posted on Slashdot after noon Central Standard Time each day that they have a message to send as their one time pad? In that way avoid the issue of having to transfer the pad between themselves in advance and they have a new text available daily.

        How is Alice supposed to inform Bob of this scheme in the first place?

        If I am intercepting their communications, I will know of their scheme and have the same access to Slashdot at noon CST to obtain their daily key just as well as they can.

        If Alice and Bob do have some "magic" method to communicate this scheme, then why should they bother with the encryption scheme in the first place? Just use the "magic" method they would have used for all their communications since it clearly must be secure, right?

        • by AHuxley ( 892839 )
          Re "If I am intercepting their communications, I will know of their scheme"
          To ensure privacy and anonymity? A one time pad gives two people, a project or an entire nation privacy. Constant fixed site messages (embassy, political leader, bank) still gets the full privacy and understands the total lack of all anonymity.
          The Soviet Union faced this question in the 1950's. They understood that their complex communications networks had no privacy or anonymity.
          The UK and US had mapped out their global networ
          • by dissy ( 172727 )

            You still haven't answered the question to the problem at hand.

            How do you securely exchange a one time pad in the first place, if all of your communications are being monitored?

            That is the one and only thing public key crypto does. Nothing secret needs exchanged, and the only thing needing exchanged is perfectly fine to be public knowledge as it doesn't let an attacker do anything.
            (Well, it would let the attacker send you an encrypted message that only you can read - but that's not a risk, that's precisely

            • by AHuxley ( 892839 )
              Thats where https://en.wikipedia.org/wiki/... [wikipedia.org] can help. Why are two ip's swapping neatly formatted random yet standard formatted code blocks?
              With anonymity lost, it is then just a race to get to the hardware and plain text as the common computer is often used to create the messages.
              Thats the honey pot in modern crypto, making random people reach out and swap keys. If they slip up or can be induced to make a mistake... or the open developer was a gov/mil front?
              It depends where a gov has placed its ski
              • by dissy ( 172727 )

                A lot to reply to, and a lot of conflicting concepts even though you are essentially correct regarding each of them.

                First, encryption alone isn't related to identification/anonymity. Those are two separate things each needing addressed.

                In fact even with public key crypto, reverse encryption (aka signing) isn't required to use, but is the only method for true identification on top of the encryption.

                For communications to be secured, only the requirement of 3rd parties being unable to read it is assumed. Ide

        • by AK Marc ( 707885 )

          If Alice and Bob do have some "magic" method to communicate this scheme, then why should they bother with the encryption scheme in the first place?

          Alice and Bob have a steganography system they believe to be unbeatable that can't be unbeatable if it is used for larger communications. But works for indicating which "pad" to use. One could presume that the steganography and pad selection was set up before the interception began. Such a system would not work well for a new communication path, but for paths that were secure when set up, than are later insecure.

  • by mlts ( 1038732 ) on Monday August 03, 2015 @04:37PM (#50243877)

    They went into Shor's Algorithm, ECC, and such... but the article doesn't seem to show what algorithm they decided to go with that is resistant to quantum factoring.

    Are they going with something lattice based?

    Would be nice to have more details on what they came up with... 20% performance can be important, but what is more important is how the algorithm resists different attacks.

    • by robi5 ( 1261542 )

      > 20% performance can be important

      why?

      • by mlts ( 1038732 )

        High volume server farms doing lots of web transactions. A 20% addition might mean having to have that many more servers behind the load balancer to handle the algorithm's added CPU load.

        However, if it does protect against an up and coming attack, that penalty might not seem as bad compared to a protocol break.

        • by robi5 ( 1261542 )

          20% is roughly the CPU speedup realized in just one year. It feels really insignificant. Also, I haven't read the FA, but making something harder to break to the tune of only one year's CPU speed advance isn't quite the same thing as making it quantum computer proof, even if someone expects commercial quantum computers in a year :-)

          • The problem is that quantum computers are theoretically able to break encryption instantaneously. This isn't 20% slower than instantaneous it's 20% slower to encrypt/decrypt when you have the key. The comparison being that a dead bolt and a regular lock takes twice as long to lock and unlock but that doesn't speak to how much longer it takes to cut through the door.

    • by datokrat ( 4207647 ) on Monday August 03, 2015 @06:20PM (#50244499)

      Are they going with something lattice based?

      Hm.. An internet search finds this one: http://research.microsoft.com/... [microsoft.com]
      The headline is "Post-quantum key exchange for the TLS protocol from the ring learning with errors problem", so it doesn't seem to have strictly to do with a lattice-based problem if it's the algorithm that was meant in the article above.
      And this is an explanation: http://csrc.nist.gov/groups/ST... [nist.gov]

      I haven't understood the problem that deeply but when I do I will post it here.

    • by Bengie ( 1121981 )
      It only affects the handshakes, then it's all AES. Stop making lots of connections and use long lived connections. But like you said, how are the measuring it. 20% just for the handshake or 20% on average per web request?
      • by mlts ( 1038732 )

        Shor's algorithm only is usable with asymmetric algorithms, so AES isn't really affected. The part that is affected is only done during the handshaking process, so if the parent is right and long lived connections [1] are used, this might soften the blow somewhat.

        [1]: I've wondered about a trade-off of space for CPU and having the TLS protocol negotiate a master session keystream (pretty much a sequence of interim symmetric keys that gets consumed to make session keys, and when the last one gets consumed,

        • by Bengie ( 1121981 )
          In theory you only ever need one symmetric key assuming you have a strong cipher like AES and you assume the handshake can't be broken.
  • by laughingcoyote ( 762272 ) <barghesthowl.excite@com> on Monday August 03, 2015 @04:40PM (#50243893) Journal

    This article is about a waste of time.

    Microsoft has developed an encryption method resistant to quantum computers, it claims. Alright? What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against? Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?

    • Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?

      Yes, it's secure because they will give all of your data to the NSA for safekeeping.

    • by ljw1004 ( 764174 ) on Monday August 03, 2015 @05:54PM (#50244373)

      This article is about a waste of time. Microsoft has developed an encryption method resistant to quantum computers, it claims. Alright? What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against? Are we just supposed to believe Microsoft when they say "Trust us, this is secure"?

      No of course not. You're meant to read this article, understand that it's an example of bad science journalism, and because of your innate geekiness and intellectual curiosity you should use the power of Google or Bing to find the scientific research in question:

      http://csrc.nist.gov/groups/ST... [nist.gov]

    • by stebilad ( 186865 ) on Monday August 03, 2015 @05:57PM (#50244389) Homepage

      What is that method? How does it differ from current encryption techniques? Why is that well suited to encrypting against quantum computers? How did you come to that conclusion, given that you don't have one to test against?

      I'm one of the authors of the research that was discussed. Unfortunately, the MIT Technology Review article doesn't contain much detail. Here's a link to our research paper: https://eprint.iacr.org/2014/5... [iacr.org].

      The scheme uses a mathematical primitive called the "ring learning with errors (RLWE) problem". Rather than multiplying large prime numbers together like in RSA encryption or using points on a curve like in elliptic curve cryptography, here the mathematical operation is based on multiplying polynomials together, and then adding small random noise. An analog of this is solving systems of linear equations: if you took first year linear algebra, you might remember that if I give you a matrix A and a vector b, you can use Gaussian elimination (row reduction) to find a vector x such that Ax=b. But it turns out that if I add a small random noise vector e, and give you A and (Ax+e), it becomes much harder to find x. Our work is about actually using RLWE, seeing how to design a key exchange protocol that's suitable for use in SSL/TLS and then implementing and testing it. (Here are some slides from a recent talk I gave about the research, which try to explain the problem in more detail: http://files.douglas.stebila.c... [stebila.ca])

      RLWE isn't our invention -- we build on existing research by Regev, Peikert, and others, and RLWE has been studied for a few years now. RSA and elliptic curve cryptography can be broken by quantum computers because they have a certain periodic structure that can be easily detected by a quantum computer using a quantum algorithm invented by Shor. But RLWE, and several related problems, don't seem to be susceptible to Shor's algorithm, nor to any of the other quantum algorithms that give an exponential speedup over normal classical computers. No one in the research community today knows if RLWE is hard for quantum computers, but right now people accept it as a promising candidate, and it is being explored for a variety of uses. If after years of cryptanalytic research no one manages to break it, then it may achieve the corresponding levels of confidence that the research community has in the difficulty of currently accepted problems, like factoring or elliptic curve discrete log.

      • Much appreciated.

      • Thanks for posting this explanation!
  • Ya, right. They'll just track your fucking battery instead.
  • by Prune ( 557140 ) on Monday August 03, 2015 @05:02PM (#50244039)

    When (or if) quantum computers become practical they will make existing forms of encryption useless.

    Uh, no. It will only make breaking certain popular public-key cryptosystems practical. There are quantum-safe public-key systems, and most symmetric ones are also safe (at best, using a quantum computer with symmetric systems is equivalent to halving the key size — with an obvious way to compensate).

  • It is so secure that a machine that hasn't been invented cannot break the code! However, with an abacus, all bets are off.

  • by stebilad ( 186865 ) on Monday August 03, 2015 @05:43PM (#50244313) Homepage

    I'm one of the authors of the research that was described in the article. Here's a link to our research paper for more information: https://eprint.iacr.org/2014/5... [iacr.org]

  • CFRG meeting. Mixing post-QC RNG into the TLS pre-master secret.
    Forward secrecy even if QC cracks RSA or ECC.

  • by Anonymous Coward

    When TFA doesn't even mention the name of the underlying algorithm, could you at least skim through TFSlides and link to Wikipedia [wikipedia.org]? Would spare all of us the guesswork next time.

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...