Monday, December 21, 2020

M42: November Orion, Revisited

 


(Click for a bigger view!)

I went back and re-processed data from 2020/11/22, used for this image. This time, I included the 10-second exposures, which is how I got the detail in the core of M42 that was blown out in the earlier pic.

I stacked 95x10sec exposures (with 15x10sec darks and the same flats I used for the earlier pic), then took that image and the 47x30sec stacked image, adjusted them so their histograms were similar, then stacked those two. It worked remarkably well; if you look closely at the two images, this one not only has more in the core, it has more detail in a few places, some of the stars are sharper, and importantly, the noise levels are substantially lower.

I think the optics & mechanics I used could still give a little more, if I shot at 200mm instead of 145mm focal length and took more lights, and especially more darks and flats. But I think this is pretty close to the limits of the data I have at this point.

Sunday, December 06, 2020

Nebulosity Processing: A Few Comments on the Orion Photo

 Yesterday I posted a photo of Orion that I'm pretty happy with. I included basic technical notes, but here are some additional anecdotes on the image and processing.

Min Yun asked about the filter (digital signal processing, not glass) I used. This was done with Nebulosity 4.4's "Std. Dev. filter (1.5 - typical)". The documentation is a shade vague, but I believe this discards everything more than 1.5 s.d. above & below the mean, then averages. In my first processing attempts I used straight "Average/Default", which would be mean. Perhaps it's partly because I got better, rather than just the difference in the filter, but this looks quite a bit less noisy than my earlier efforts. Min suggests I try 50th %ile, just using the median. Turns out the software supports that. Hmm, I should give it a shot.


Here's a view of one of the raw images, zoomed in around the Horsehead and Flame.


Look at the tool on the right, and you'll see I've set the display to rescale color in the range 2500-2800. This is after demosaicing (turning the raw black & white pixel values into a color image), but with no other processing done on it. If you look closely at the histogram,  you'll see three peaks, which (left to right) are green, blue and red. The current scaling basically hides all of the blue and green. The reds on this camera accumulate counts much faster than either blue or green, which I've spent a LOT of time investigating. When I first saw these, I assumed it was skyglow from city lights, but the same thing is true for my dark frames, so it's the sensor. I don't know if there is some camera setting I should be adjusting, or if I should be tweaking the raw import function. Nebulosity supports a modest number of Canon models, but doesn't have a direct entry for the EOS 7D. I tried them all, some were different, none were better. (As an aside, I would find a better histogram tool, that showed three separate curves, useful; most imaging programs, like GIMP and Photoshop, have that as a default. I think the author of this software does a lot of his work one channel at a time, before combining colors and doing finishing work in another tool.)

Below the bright star you can see the Flame Nebula, standing out above the noise. In the center of the image, you can maybe, maybe, see a dark spot emerging? That's the Horsehead.

Here's the exact same region of the image, after stacking 47 exposures and using 13 dark frames to reduce the floor.  (Note the differences in the histogram and in the B & W sliders. The values are different both because of the dark removal and averaging, and because the above one was 14-bit Canon raw, and this is 16-bit FITS.) Now we have a view!




Next we do a power stretch, to bring up the details on the bottom end of the intensity scale. (n.b.: this is also necessary to keep the Orion Nebula, M42, in a reasonable range; clamping the values like the image you see above turns M42 totally white. M42 is to the right and above, out of frame in this zoomed view, but is important to the final image.)



And now we're pretty much there! I did one final tweak in GIMP to raise the middle of the dynamic range while keeping the top and bottom the same, which gave the image you saw yesterday.

Here's a close-in zoom of the Horsehead, after all the processing. (Click on it to open up and look closer.) This is the number of pixels I've got there, and you can still see some noise. You can also see how good my alignment and mount are, as well as limits of the optics and seeing, by looking at the stars. The really oblong one at the horse's neck is probably an unresolved double star, which you can tell by comparing it to the surrounding stars. The others show drift toward the lower right of about two pixels, which I calculated elsewhere is about the amount of movement in one thirty-second frame.



All of this took me about twenty hours of learning and fiddling and watching YouTube and reading docs, though it sounds simple once I summarize it like this. There are a lot of tutorials on the web on astro image processing, but figuring out which ones to watch is a chore in itself!

Min asked if I'm doing anything about cosmic rays. Not particularly. The dark frames handle "stuck" (or "hot") pixels as well as the current that accumulates even when no light is coming in. With only 47 light frames and set at ISO 1600, you can see that there is a ton of pure noise; I think most of that is thermal/shot noise rather than cosmic rays. A lot of serious amateur astrophotographers have adopted cooled CCD cameras, that work at -10C to -30C. I'd like to have one, but they seem to be expensive, and no doubt are a learning curve in their own right.

To return to the "red accumulates faster" thing, here's M42 from one of the raw images without any adjustment.





Oh, and the final interesting thing from the shoot itself: a train of high-altitude, very dark satellites flew smack through the middle of M42 while I was shooting! Here's a view from the same raw image above.





There are about five of them, moving very slowly and obviously very dark. It took them about 3-4 minutes to cross the area of my frame, about 5 degrees. That's the amount of time it would take an LEO satellite or the ISS to cross the entire sky. They must be thousands of km up. I kept the frames they cross in my total stack, but their trails are tossed out by the stacking algorithm.

Hope you enjoyed this tour through my brain, and my last couple of weeks. See you in the stars, or at least online. Stay safe!


Saturday, December 05, 2020

The Importance of Polar Alignment

 One of the major innovations in amateur astronomy since I was a kid is the regular use of polar alignment scopes. They existed, but were beyond my budget and patience as a fifteen-year-old. Now they are standard features on a lot of mounts, including my Kenko Sky Memo S.

So, how good does your polar alignment have to be for astrophotography?

Let's say you're off by one degree, toward R.A. 0, for simplicity. That means that if you're aiming at something at the equator (where the effect will be the worst), your aim will be a degree low at R.A. 0 and a degree high at R.A. 12h. The maximum slew rate will be when you're looking at R.A. 6h or 18h.

How fast is that slew rate? Let's see...that up and down cycle will be two pi per 24 hours...max slope of a sine wave is 1, but gotta match those units...one radian per 3.82 hours...so that would be a max rate of one degree per 3.82 hours. That's 15.7 arcminutes or 942 arcseconds per hour. About one arcsecond of drift every four seconds.

Is that a lot? Well, my professional astronomer friends tell me the seeing at sea level is about 1 arcsecond, at best. It's also about the diffraction limit for a 100mm objective, roughly. So worst case, this would limit our exposure time to four seconds, if our alignment is off by a full degree.

But whether we are working near that limit depends on focal length and camera resolution, too. My Orion photo I just posted was about 3k*5k pixels in the original, covering about 5x7 degrees (before I cropped), shot at 145mm f.l.  I calculated that one pixel in that image is about 6 arcseconds.  (All of this is very back-of-the-envelope, so call it 4 to 8 if you're picky.) So, a 1 degree misalignment would drift by 1 pixel in 24 seconds (well, 20-30, give or take). Since I was stacking 30-second exposures, I only needed to be within one degree!

Very roughly, eyeballing my raw images, over about 25 minutes I drifted by about 90 pixels, about two pixels per shot. A little more than I'd like, but with the stacking I did, not noticeable. In fact, zoomed all the way in, the best stars don't really show any distortion in that direction.

So, I thought I had the polar alignment really nailed during that shooting session, but I might have been off by a full degree. (As it happens, I had to allow rotation as well as translation in the alignment of my stack, which may be due to polar misalignment.)

So I'm in pretty good shape for 30sec exposures with the Canon 70-200mm zoom lens. But if I'm going to shoot long exposures with the new C90 Mak, f.l. 1250 and f/14, I'm going to have to do a lot better than one degree. (I'm also going to need a lower-vibration mount.)

Of course, serious astrophotographers shooting at long focal lengths usually guide their scopes, for exactly this reason, using a longer-f.l. scope and a lighted reticle eyepiece to keep the imaging rig pointed right. It's pretty arduous work. But technology is making this one easier, too, if you've got the budget!

Orion: M42, M43, Horsehead and Flame Nebulae

M42, M43, Horsehead and Flame Nebulae in Orion

This is the same data I've been working with for a few weeks now. The two bright stars on the left are two-thirds of Orion's belt, and the bright nebula on the right is the main part of his sword hanging down.  (The image is rotated 90 degrees from what we usually think of as "up" with Orion.) Specs:

  • Camera: EOS 7D
  • Lens: Canon EF 70-200mm f/2.8
  • focal length: 145mm
  • f/2.8
  • ISO 1600
  • Mount: Kenko SkyMemo S equatorial tracker
  • Exposure:
    • lights: 47 frames, 30 seconds each
    • darks: 13 frames, 30 seconds each
    • flats: 10 frames using above setup, but I don't really trust them
    • bias: none (should I? given how much noise is the problem here...)
    • First aligned with rotation (two-star alignment), then stacked using std. dev. 1.5 filter, throwing out extreme points
  • Field of view: approx. 5x3 degrees as cropped
  • Image size: 3338x2225 as cropped
  • Resolution: very roughly, 6 arcseconds per pixel, smallest stars are about 4x4 pixels, so 25-30 arcseconds resolution, I guess, but the brighter stars are about 20x20 pixels
  • Faintest stars in the image: good question! I wish I knew.
  • Software: Nebulosity 4.4.3, GIMP 2.10
  • Date/time: 2020/11/22, about 2:00 a.m. local time
  • Location: Arakine Dam, Chiba, Japan
I have learned a ton about CCDs and image processing, but I have probably learned more about this specific camera/sensor and this specific piece of software than about the principles. Because I had so much learning to do, this photo is probably about 20 hours worth of sitting in front of the computer working.
I'm also sitting on 100 frames at 10 seconds, which might add some detail in the middle of M42. I don't know if it's possible to combine them effectively with this or not. I would still like to make the Horsehead more vibrant, but M42 is so bright, that everything I've done to try to brighten the Horsehead turns M42 into just a wash of white. More to learn, yet, but I think this is pretty close to all that this data has to give.
I'm having fun...

Tuesday, December 01, 2020

C90 Mak: Saturn


 Best shot I got out of a couple of dozen.

Prime focus, 90mm objective, 1250mm f.l., f/14, ISO 800, 1/10th of sec. C90 Mak lens, EOS 7D camera.

Kenko SkyMemo S equatorial tracking drive & accompanying wedge and tripod, roughly hand-aligned using a level and compass (no line of sight to Polaris, and set up before dark, anyway). Vibration is a big problem at this f.l. Most of my shots, even with a 1/10th second exposure, were smeared.


Saturday, November 28, 2020

C90 Mak First Light: the Moon!

 

From my first session with my brand-new Celestron C90 Mak. f.l. 1250mm, f/14, so it's not bright. And yet, with my EOS 7D set at ISO 800, this is 1/400th of a second, and even half that might have produced good results.

It was also cloudy; this was snapped between the clouds, and actually with a little haze still present. Kenko Sky Memo S equatorial mount and clock drive, with alignment only guessed at using a compass, and yet the tracking worked reasonably well -- about as well as I ever used to manage with my old Edmund Scientific reflector, but not nearly as good as I managed last week using the polar scope.

If I'm doing the math right, a 90mm objective observing 600nm (orange) light has a diffraction limit of 8 microradians, or 1.65 arc-seconds. The moon here is about 2700 pixels across, smallest features are 5 pixels or less, call it 1/500th of the moon's diameter. 1/500th of 1800 arc-seconds is about 3.6 arc-seconds, so I might actually be close to the maximum theoretical resolution? Off by less than a factor of two would be pretty good. At first glance, I didn't think this scope was anywhere near that good. There does seem to be some scattering I can see in some of my test images, which definitely adds noise/reduces contrast.

Definitely still a lot of learning to do to get the best out of this new tool, but not a bad first effort.

Friday, November 27, 2020

Beginner's Guide to Working with Nebulosity 4

 


I've been getting back into both photography and astronomy, so, astrophotography. The picture above is the Orion Nebula, shot on Nov. 22, 2020, and processed with Nebulosity 4 software as well as Gimp. It represents my best effort so far, in optics (improved focus and exposure), mechanics (polar alignment, tracking and vibration), and image processing. I think the raw data I took that night still has more to give, so I'll keep working on it. Click on the image for an expanded view!

Nebulosity 4 is astrophoto software that can control some digital cameras and provides a great many editing features for the resulting images. I acquired it because I liked its image stacking features the best of three or four tools I tried on the Mac, but I'm gradually using more of the features. I don't have any real plans to shift to full laptop/software control in the field right now, but you never know.

It turns out that, despite the more-expensive-than-a-game-but-ridiculously-low-for-professionals price of US$95, documentation is a little sparse, so it has taken me a while to kind of grasp the expected workflow, including learning about darks and flats and biases. Most frustratingly, after learning about those concepts, I spent quite a while trying to understand the basic mechanics of working with Canon CR2 raw image files. So, I'm collecting what I've learned so far, in this blog post.

Resources:

  • Really, the first thing to look at is the Nebulosity 3 manual, since there is (AFAICT, as of 2020/11/26) no separate Nebulosity 4 manual yet. (Frustratingly, I kept the link directly to that PDF, but not the page that linked to it, and now I can't find the web page -- an indication that the website needs some love? Ah, found it again -- it's under "Downloads", but you have to scroll down.) In that document, on p. 29, you'll find a nine-step formula for processing images -- exactly what I was looking for, and which took me hours to find. It's the basis for what I write below.
  • This YouTube video by Alex Cardenas is fantastic. It's a near-perfect tutorial on how to do the stacking in Nebulosity, once you have your set of frames ready. However, Alex was working from separate sets of R, G, and B files, whereas I'm working first from JPEGs and then from Canon raw files.
  • This info on Canon CR2 raw image files was a big help in learning about what's going on in the raw files themselves, and what needs to happen to turn them into color images. In particular, Section 4 of that shows how pixels are laid out on the sensor chip, which helps you understand what you're seeing if you are looking at the whole raw file in black and white. Armed with this info, I was able to figure out what operations needed to happen, then the next step was to learn how to make them happen in Nebulosity (see the first bullet point in this list).
  • This presentation by Craig Stark from 2014 is good enough to be useful, but it's long, almost two hours. The best part I've seen so far (I'm about halfway through) starts at 22:10, discussing the basic linear math of what he calls "Classic dark subtraction". I'm sure there are other good sources on the particular topic on the web.
I'll put more about my process into another post.

The image at the top:

Orion Nebulae M42, M43, in the sword hanging down from Orion's belt. The image is turned sideways; the two bright stars to the left are two-thirds of the belt.  Around the lower one (left as we usually think of it), Alnitak (zeta Orionis), there is visible also a bit of nebula.

  • Camera: EOS 7D body, APS-C sensor
  • Lens: Canon EF70-200 f/2.8L USM lens, set at 145mm f.l.
  • Settings: ISO 3200, f/2.8, 30 second exposures
  • Mount: Kenko SkyMemo S equatorial drive and leveled tripod
  • Images: high-quality JPEG
  • 47 light frames
  • 15 dark frames (camera is old, with a lot of stuck pixels, so the darks really help!)

The focus may not have been perfect, but was pretty good; achieved using simulated exposure and digital zoom to set focus, and at max zoom could see quite a bit of vibration from the mount.

I'd like to reshoot with zoom set at 200mm, and possibly stopped down to see if that reduces some of the coma, but fundamentally I think this is pretty close to the capability of this lens, sensor and mount.  Raw images are also pretty noisy, should try ISO 1600 or even 800.

Shot around 3am local time, about 3.5 hours before sunrise.  Shot at Arakine Dam, Chiba Prefecture; perhaps the best dark within two hours' drive of our house, but you can still see quite a bit of sky glow from Chiba city and Tokyo.  The Himalayas it ain't.

Stacking done with Nebulosity, which seems to be excellent for this task.  A little more flexibility in adjusting the light curves would be nice, but that's easy in Gimp once the alignment and stacking are done.  For this image, I simply set a black level floor of around the sky glow, no other light curve tweaking; cropped in Gimp.

Sunday, October 04, 2020

The Organizations I Work With, Or, Where my Time Goes

 If you're waiting on an answer to an email from me, or I owe you a document, or for some reason my inability to get something done is inconveniencing you, I apologize.  I really shouldn't spread myself so thin, but the fact is that there are a lot of things in this world I care about. Worse, as a professor, I don't have a boss. The great thing about not having a boss is that nobody tells you what to do. The terrible thing is that nobody tells you what not to do.  There's no one to defend you: "That's a great project, but Rod's busy. He's available the middle of next year, or you can find some else."

As a prof, we have essentially four major duties:

  • Teaching: one of the big, obvious ones.
  • Research: the other big, obvious one. This includes both doing the research yourself, and managing the research (budgets, schedules, purchasing, hiring, etc.).
  • University service (running the university): the amount of this varies depending on your position, how useful you are (making yourself useless/unreliable gets you out of some of this), and the structure of your institution.
  • Community service: participating in your community, defined however is appropriate for you. Might be the literal community around your campus, might be running a journal or a conference.
For me, and for most of us, community service means working with colleagues in our own and other universities, companies, government labs, and government committees,  to further the field as a whole. In some cases, this benefits your own research projects, in some cases it's much more indirect.
My primary research area, as you probably know, is quantum computing and quantum networking, but I also care about computer networking in general, and distance education and educational technology (though I have no formal training in the latter).
So, here are most of the organizations I'm working with these days (as of 2020/10/1). Some of these are internal to Keio, i.e. a structure for doing research.  Others are external.
  • AQUA: my own quantum computing & quantum networking research group at Keio's Shonan Fujisawa Campus. Truly, the center of my professional life.
  • RG: our larger lab on campus, an umbrella for managing over 100 undergrads in a broad variety of computing areas.
  • AQUA @WIDE: there is also the AQUA working group inside of the WIDE Project. We generally hold a small meeting during the semi-annual WIDE Camp, or run a tutorial during the semi-annual WIDE Kenkyuukai, things like that.
  • WIDE: I'm a WIDE Project Board Member. I do much less for WIDE than most of the other board members, but even so I do quite a bit.
  • KQCC: the Keio Quantum Computing Center, where I am Vice Center Chair. I supervise and participate in a good fraction of the research, but the Founder and Center Chair have actually done most of the heavy lifting on paperwork, recruiting member companies and partners, hiring, etc.
  • CCRC: the Keio Cyber Civilization Research Center. Rather than a driver, I'm a participant here, but this is important work, as well.
  • SOI-Asia and AIII: my involvement here is small, but I do what I can. We're working with some of the SOI-Asia partners to share our MOOC on quantum computing, including translating the MOOC into important languages in Southeast Asia. I also have one Ph.D. student working on technology in language teaching, and this is one of her primary "homes".
  • AINTEC: I'm on the steering committee for the Asian Internet Engineering Conference.
  • JFLI: I'm Keio's representative to the Japan-France Laboratory for Informatics.
  • QIRG: I'm co-chair of the Quantum Internet Research Group, part of the Internet Research Task Force (IRTF).
  • IRSG: being co-chair of QIRG puts me on the Internet Research Steering Group. This means I should be doing a lot more for the IRTF as a whole than I have been.
  • QITF: here in Japan, we are standing up the Quantum Internet Task Force, bringing together most of the researchers in Japan who are working on quantum repeaters.
  • WQRN: I'm part of the organizing committee for the Workshop for Quantum Repeaters and Networks.
  • TQE: I've joined the editorial board of IEEE Transactions on Quantum Engineering, for the moment as an editor for the special section but probably more work coming up.
This doesn't even list the campus committees and program (department) duties, etc. It also doesn't even begin to address handling my research projects -- all that's just lumped under "AQUA" up there at the top.
And in a normal year, I travel to visit collaborators in Thailand, Paris, U.S., Hyderabad, etc., not to mention the conferences and meetings. I often feel depressed and overwhelmed by work, like I'm not getting anywhere near enough done. But then I look at this list, and wonder how I ever get any sleep and time at home.

[Edit on 20/12/3: Add JFLI]

Sunday, June 07, 2020

5.1 Shor 'Nuff

(See the top of this set of postings.)

Obviously, the main thing we're talking about here is Shor's algorithm.  I have not been privy to the conversations of cryptographers in creating post-quantum crypto, though we'll take a short look at that below.  But there are very few people in the world who understand better than I do what it takes to actually run the full version of Shor's algorithm on a potentially real machine.

A full implementation of Shor's algorithm consists of two quantum phases: modular exponentiation, followed by the quantum Fourier transform.  (I'm assuming you're familiar with the main ideas behind Shor, how it uses interference to build patterns in the quantum register that can reveal the period of a function that allows us to find the factors of a large semi-prime number.)

The key insight may be the behavior of the QFT, but the bulk of the execution time will be in the modular exponentiation phase.  This is actually one of the areas that I worked on in my Ph.D. thesis.
Some of the important parts of this were published in Physical Review A.

In my thesis there is a plot that I think is useful, which we updated and published in our Communications of the ACM article:

We worked out detailed performance estimates, including hardware requirements and quantum error correction, in some of our papers:
and

There were other, contemporary important papers on how to implement Shor, including Fowler et al.,  https://arxiv.org/abs/quant-ph/0402196 who discussed Shor on a linear array, a few months ahead of my own Phys. Rev. A paper on the same topic.

We both built on important, early work by Vedral, Barenco and Ekert (VBE) and by Beckman, Chari, Devabhaktuni and Preskill (BCDP).

If you are looking to broaden your reading on implementations of Shor’s algorithm, the following are useful:

Pavlidis and Gizopoulous found an efficient division algorithm, accelerating the math.

Roetteler, Steinwandt focused on the applicability of Shor's algorithm to elliptic curve. I like the paper, except I think their survey of related research could have been better.
and Roetteler, Naehrig, Svore, Lauter:

Gidney and Ekera submitted to the arXiv a paper on factoring a 2048-bit number using 20 million noisy quibits.  In this paper, one of their techniques is arithmetic "windowing" which is essentially identical to one of the techniques I proposed in my 2005 Phys. Rev. A paper.  https://arxiv.org/abs/1905.09749

May and Schliper also recently uploaded a paper on period finding with a single qubit.

Ekeraa and Hastad also proposed a new period-finding algorithm variant, in 2017.

Smolin, Smith, Vargo wrote something of a warning about inferring too much from very simple demonstrations on a few qubits.

Here is one early paper on how to assess errors in Shor’s algorithm, by Miquel, Paz and Perazzo:

Chuang et al., also published an early examination of decoherence in factoring.

Among random things, there is Dridi and Alghassi, factoring on D-Wave; I don’t think this paper tells us very much about factoring at scale.

That's more than enough for now, since it isn't really the focus of what we're after here, anyway.

5. Attacking classical cryptography using quantum computers

Naturally, my own interest in writing these notes stems from my experience in quantum computing and quantum networking.  The previous sections dealt primarily with classical attacks, with a little bit of quantum networking can be integrated with classical thrown into each section.  Here, let's look at the attacks on classical cryptography using quantum computers.

4.4 TLS and QKD

Alan Mink, Sheila Frankel and Ray Perlner worked on integrating TLS with QKD, a full decade ago.

4.3 Other Attacks on TLS

One startling and potentially useful document is RFC7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)".  It details a couple of dozen attacks on TLS, most having to do with protocol implementation issues such as failing to correctly verify all of the information you are given.  Some of them leak information or allow a connection to be take over, others allow an attacker to downgrade the security negotiation so that a later attack on the cipher has a higher chance of success.

One attack this RFC points out is http://www.openssl./~bodo/tls-cbc.txt, which (among other things) describes a flaw in how TLS Record Protocol records are concatenated. Originally, TLS kept the ciphertext of the last block of a record to use as the initialization vector (IV) of the first block of a new record, but this allows an attacker who can adaptively choose plaintexts to more completely choose the text being encrypted.  The fix is straightforward (toss in an extra block of nonsense data before starting the new record), and current versions of TLS aren't vulnerable.

4.2 Keying and Rekeying

(To be filled in.)

<>

<sure that an attacker can't cause a downgrade of security relative to
what both ends really want.>>

<>

4.1 TLS Records and Basic Limits

TLS consists of one primary protocol: the TLS Record Protocol.  On top of the TLS Record Protocol sit four protocols, one of which (the application data protocol) is used for the bulk data encryption, and the TLS Handshake Protocol, which utilizes public key cryptography to establish identity, securely creates a shared secret to be used for the bulk data encryption, and makes sure that this part of the process can't be modified by an attacker.  A third one of interest to us is the change cipher spec protocol.

A record in the record layer has a maximum size of 16KB ($2^{14}$).

There is, as best I can tell, no official limit on the key lifetime or on the number of bytes that can be pushed through a single TLS except the limit on record sequence numbers of $2^{64}-1$.  Combined with the max record size, that's $2^{78}$ bytes, or 256 exabytes, which is a bloody lot of data.  So, if the lifetime of a session needs to be limited, it has to be done by breaking the connection and renegotiating. Apparently, adding a key renegotiate feature was considered for TLS 1.3, but doesn't seem to have been included.

Luykx and Paterson wrote up a short (8 page) summary recommending limits for TLS with different cryptosystems. (My copy is dated Aug. 2017, but the paper was referred to in Apr. 2016.) http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf
Unfortunately, that paper has good references but doesn't go through the complete reasoning, so going one level deeper in the reading is really necessary.

In April 2016, Mozilla moved to limit the length of a connection, based on those results:
https://bugzilla.mozilla.org/show_bug.cgi?id=1268745
They set AES-CBC to about $2^{34.5}$, or about 24 billion records, about 400 terabytes max.  That should give a probability of $2^{-57}$ of "ciphertext integrity [being] breached", though I'm a little unclear on exactly what that means here -- is this just birthday bound leaking some plaintext, or is this compromise of the entire session key? Figuring that out will take more digging, since they express things differently than most of the resources I used above.

4. TLS/SSL and cryptography


(Back to the top of this sequence of postings.)

Here we want to answer the same three questions we had above about IPSec:
  1. What are the technical mechanisms in place for rekeying and effective use of encryption?
  2. What was known, at the time these protocols were developed, about the best practices for rekeying?
  3. What are best practices today?
but this section will be much shorter, as I know so much less about TLS (despite the fact that it is the most important use of encryption on the Internet today).

The current standard for Transport Layer Security, or TLS, is RFC8446, published in 2018.  It specifies version 1.3 of the protocol.  The main document itself is only 160 pages, not bad for something so complex and important.

...oh, what is TLS?  It's the protocol that HTTPS runs over.  It's the successor to SSL, the Secure Sockets Layer, which was the first way to encrypt web browsing.  TLS originally built on top of a reliable transport protocol, such as TCP, though a later adaptation (RFC6347) lets it run over a datagram protocol.  We'll only worry about running it over TCP here.  TLS provides privacy, by encrypting all of your web browsing traffic for a particular connection.  It also provides data integrity, using a MAC (message authentication code) when necessary. (IPsec also does both, but we ignored that above.)

Thursday, May 28, 2020

3.4 IPsec, Quantum Computing and QKD

(Back to the top of this sequence of postings.)

(This one is just a placeholder, but there is surprisingly little documented about this kind of work.  Even e.g. the publications describing the recent Chinese QKD satellite experiment say, "We used AES plus QKD," or, "We used QKD-generated keys as a one-time pad," but they tell you nothing about the network or transport layer protocols used, so who knows?  Might be documented elsewhere on the web, or described in talks, but so far I've failed to track down anything authoritative.)

Chip Elliott was the first to modify IPsec to work with QKD, as far as I'm aware, described in a 2003 SIGCOMM paper.  Shota Nagayama drafted and implemented a more formal protocol modification for his bachelor's thesis working with me, back in 2010, but we failed to push that from Internet Draft to RFC.

(More to come here, eventually, on both the use of QKD with protocols such as IPsec and on how effective quantum computers will or won't be at breaking communication security.  Some of this will also be covered in Section 5.)

Tuesday, May 26, 2020

A #QuantumNative Engineer's Bookshelf


Quantum computing involves three major technical areas: mathematics, physics and computer science and engineering, and a fourth, important area: society. What does a new engineer, or student, aspiring to be a #QuantumNative need to know? Unlike some other researchers, I do not think it's necessary to learn physics first, or computer science first. I think you can dive straight in and learn quantum computing without insisting on quantum mechanics as a formal prerequisite. In fact, that's how you become #QuantumNative -- by learning quantum computing in parallel with classical. But, I do think there is  a structure to all of what you need to know, and an ordered walk through that will ease your way.
One of the duties of a university is to create a curriculum that provides structure to the body of knowledge. A book provides structure to a subset of that knowledge. Research papers move us forward, but assume a lot and ignore even more. Simply hopping around the web, looking for what you need at the moment, leaves gaps and causes you to miss things that an engineer with a more carefully curated set of knowledge will pick up on. Build your mental toolkit well, and you will be rewarded.
While books aren't the only way to learn, they are perhaps my favorite, so let me do this in terms of a bookshelf. These are not merely trophy books to look good, they should be used; by the time you're my age, they should be battered, coffee-stained and full of highlights and notes in the margins.

Many of these titles can be swapped out for similar, in some cases more modern, ones, but a few are truly unique, and several have their own Wikipedia pages. I think you'll see which are which.

Of course, if you're an undergrad, getting through all of these in four years will require focus and dedication, while at the same time, you must also keep up your social life, physical and mental health, and non-technical learning.  But hopefully these books will help guide you in good directions as your career develops.

Popular Science and on up to Beginners' Recommendations

  • Hillis, The Pattern on the Stone: my single favorite popular science book on what a computer is.
  • Conery, The Imposter's Handbook: hard to do better than this for a quick-and-dirty tour of CS, if you program a bit and are trying to get oriented to the more formal aspects, as well as the "secret handshake" lingo that gets tossed around by experienced hands.
  • Fortnow, The Golden Ticket: the best layman's introduction to computational complexity.
  • Williams and Clearwater, Ultimate Zero and One: when I was getting started in quantum computing, this popular science-level book cleared up a number of concepts for me. Now there are many popsci books on quantum, so it may have been surpassed, and certainly some will be far more up to date, so I don't mind if you swap this one out for a favorite of your own -- but it worked for me, and it will work for you.
  • Feynman Lectures on Computation: now quite old, and always quite idiosyncratic, but I was there; you'll find my name in the acknowledgments at the beginning. Feynman opened my eyes to the ideas of computation, perhaps even more than Carver Mead, from whom I took CS1 three years earlier. The book is deceptively simple; you can understand most of the content with minimal background, but that doesn't mean it's really a beginner's book. This will, inevitably, force you to rethink what you know about computers. What a broad-ranging way of thinking...
  • Sutor, Dancing with Qubits: this is intended to be, and is quite successful at being, more than a popsci book, but I've put it here because of its accessibility and how little it presumes you know; it begins with the very basics of binary numbers and complex numbers. The book is almost evenly split between background material (the first 200 pages) and quantum computing (the next 250). Yes, there's quite a bit of math in it, so it's more intense than a popsci book, but you won't regret it. Perfect for college freshmen. Aspiring #QuantumNative engineers could do far worse than making this the first real CS book they buy.

Mathematics (Both Pure and Engineering)

I have opinions on the topics, but fewer on the choice of books. Feel free to improvise here.
  • Margalit, Rabinoff, Interactive Linear Algebra: as it happens, this will not only teach you piles and piles of important math, it will also show you what a textbook can be in the modern era.
  • ...some calculus book or another: differentiation, integration, ordinary differential equations, introductory partial differential equations. I learned all this, and linear algebra, from Tommy volumes 1 and 2, which have a unique pedagogical approach. I recommend Tommy, but with no real experience with other books I can't much compare.
  • ...some probability book or another: both discrete and continuous.
  • ...some statistics.
  • Jungnickel, Graphs, Networks and Algorithms: Why isn't graph theory core to more engineering programs?!? It's usually relegated to graduate school. As computer engineers, we learn about spanning trees, shortest path and directed acyclic graphs (as in compiler optimization), but there is so much more...Diestel is the classic but is heavy going, definitely a graduate-level text. This book is a good compromise, but feel free to substitute Diestel or something else.
  • Oppenheim, Willsky, Hamid, Signals and Systems: you gotta know Fourier transforms and other transforms. Gotta. As in, must, required, not optional.  Fourier is fundamental, but quadrature modulation (used in the not-quite-extinct NTSC) was maybe the most interesting thing I learned, simply because I found it so counterintuitive that it worked at all. I learned from the first edition of this book. This book appears to be considered a classic, but again feel free to substitute.
  • Kleinrock, Queueing Systems: Volume 1, Theory: this will change the way you think about computer systems, networks, and even going to the bank. Depending on the university, often taught to graduate students in electrical engineering.
  • Cover and Thomas, Elements of Information Theory: information theory is its own distinct field -- not just math, not electrical engineering, certainly not pure computer science -- but I have reluctantly categorized it here. This is the classic text for classical information theory, though the basics are actually covered quite well in Wilde's quantum book, so perhaps you don't need both.

Computer Science

I'm including algorithms and machine learning here. Notice that there isn't really a pure theory book here focusing on complexity theory, but we have Fortnow above and Aaronson below.
  • Cormen, Leiserson, Rivest, and Stein, Introduction to Algorithms: this book will repay every moment you put into it.  It's more than just algorithms, it includes a lot on data structures and of course assesses the complexity of algorithms and structures, as well.
  • Guenin, Könemann, Tunçel, A Gentle Introduction to Optimization: a very mathematically-oriented introduction, I have used this book in my class.  I think it's a good intro to linear programming and the seminal simplex algorithm, for matrix-oriented optimization. I didn't find the math-oriented approach to be as enlightening for graph problems; I didn't even recognize Dijkstra's shortest path first algorithm for what it was in the unfamiliar notation. Overall, I think the book lives up to its name. If you want to substitute Papadimitriou and Steiglitz's Combinatorial Optimization: Algorithms and Complexity here though, I think you have made an excellent choice.
  • Russell and Norvig, Artificial Intelligence: A Modern Approach: a must-have for a complete bookshelf, this covers everything up to the machine learning revolution below, focusing on GOFAI and symbolic and algorithmic techniques. I learned the A* algorithm from this, for example.
  • Goodfellow, Bengio, Courville, Deep Learning: a just-right book, in the right place at the right time with the right depth, written just long enough after the revolution of 2012 to digest its importance, and soon enough to be timely. With the above, a great pair.
  • Petzold, The Annotated Turing: I have several books on Turing, and several other books on the history of computation, but I am by no means an expert on the topic. Out of my modest collection, though, I would tap this one. There is so much more in it than just Turing's seminal paper, but it stops to explore every nuance. It really changed the way I view Turing machines.
  • Knuth, TAOCP: do not buy these books until you have decided to dedicate your life to computation. But once you have made that decision, and once you think you understand algorithms, buy these unhesitatingly and spend as many hours with them as you can. In the problems sections alone you can find topics for an army of Ph.D.s. These books, perhaps more than any others on the list, will cause your hair to stand on end when you finally grasp a topic.
  • Numerical Recipes: I believe, if you're going to create quantum computers that surpass classical ones, you need to have something of an organized understanding of how classical computers do numerical computation. Of course you'll find some of this in Knuth v. 2, and in any good book on algorithms, but the focus there is generally on higher-level data structures and algorithmic approaches, rather than the details of the computation itself. It used to be that software engineers had to write a lot of math code themselves, but these days good libraries for linear algebra, statistics, transforms, and numerical methods for differential equations are available. This is good for programmer productivity, software portability, and even performance, given that not everyone wants to speed months tuning code.  But it's bad for learning about the underlying machine and methods, which I think are important for engineers to know. These days, also, a lot of purely numeric code can run well on GPUs, which is a whole other matter involving a lot of learning about data parallelism. So, the book Numerical Recipes is likely outdated, but I haven't yet found a substitute.
    Asking about this caused quite a conversation on Twitter, where the general recommendations were "function libraries" and "ask on Stack Exchange", both of which are great but don't build organized understanding. People also hastened to point out that the software libraries themselves that accompany the book are licensed commercial software, and the free libraries and language features have made them less valuable. Moreover, some people don't trust the material, and recommend Netlib or any of half a dozen other implementations instead, but what I'm after here is an understanding of how to implement numerics.  I'd say this is optional.
  • Foley, van Dam, Feiner, Hughes, Computer Graphics: all right, this is really optional, but you'll learn a lot about how math and computing go together in the real world, and how data reaches humans as information is an important topic.

Computer Engineering

What's missing here is a good book on the modern state of VLSI, including its limitations. There is some material on semiconductor physics in Gershenfeld, below, though. I have, reluctantly, left databases and web/information systems off this list; we have to draw the line somewhere. A complete understanding will extend to parallel programming and to distributed systems, as well.
  • Hennessy & Patterson, Computer Architecture: A Quantitative Approach: I have had multiple copies of the classic as it has evolved over the last thirty years (one signed!). This is nominally a graduate-level text, and it's very tempting to put in the more basic Hardware-Software Interface as a nice introduction to how computers actually perform their calculations, but the important ideas are presented so much more powerfully here.
  • Arpaci-Dusseau and Arpaci-Dusseau, Operating Systems: Three Easy Pieces: a very nice overview of key principles in an operating system, organized around virtualization (of CPU, memory, devices, even whole machines), concurrency, and persistence. I used to use Tanenbaum's Modern Operating Systems, but I'm afraid it's now too old, out of step with current practice. Sometimes the structure and humor in OSTEP both feel a little forced, and I would do things a little bit differently if I were writing, but overall I think this is the best introductory book on operating systems out there.
  • McKusick, Neville-Neil, and Watson, The Design and Implementation of the FreeBSD Operating System: building on decades of its predecessors (I'm especially fond of the shorter and admirably lucid, but now outdated, book on 4.3BSD), this is the single best explanation of the structure of a OS known to humankind. Read this book!
  • Aho, Sethi, Lam and Ullman's Dragon Book (well okay, that's not the formal name): Most people would place a compilers book under CS, even under theory, but I view programming languages and compilers as one of the three pillars of computer systems, alongside OS and architecture -- a legacy, I suppose, of having first been introduced to leading-edge computer systems research by reading an ASPLOS proceedings. You simply must learn about lexical analyzers and parsers and their relationship to finite automata and pushdown automata, as well as code generation and optimization. Yes, yes, there's a strong connection to theory here -- that's the point.
  • Kurose, Ross, Computer Networking: a Top-Down Approach: obviously -- obviously -- you need a book on networking, ideally one that focuses on the Internet and its protocol suite, but that understands telephone networks, both fixed and mobile. Kurose seems to be the introductory textbook of choice these days, but I'm okay if you have a different choice.
  • Stevens (and Fall, on the recent edition), The Illustrated TCP/IP (vol. 1 and 2): you also need to understand the joys and pains of creating implementations of the Internet protocols. This might feel secondary if you're working in quantum computing, rather than networking, but it's ultimately part of understanding computer systems. This book influenced many people. After Stevens died, I was at a conference where his wife picked up a lifetime achievement award in his honor, and there was a standing ovation and people were crying.
  • Jain, The Art of Computer Systems Performance Analysis: another broad-ranging must-have.

Software Engineering

Michał Stęchły pointed out that I didn't have SE on this list. What an oversight! More coming soon.

Physics

Physicists, both experimental and theoretical, will be shocked at how few books I list here. Of course, the more physics you know, the better your understanding of the devices will be, but in fact to become a quantum software engineer, surprisingly little true physics is required. In today's NISQ environment, I'll venture, a higher requirement for physics is required than will be the case in a decade or so -- just as many great software engineers have a basic grasp of computer architecture but almost no grasp of the underlying semiconductor physics in computer chips.
Quantum physicists will recoil in horror at diving straight into quantum computing without learning about momentum and forces and energy, but I think you can actually defer much of that learning until later. I do think learning about damped harmonic oscillators is valuable, and that does require some of those other topics, though. Also, make a pit stop for Boltzmann and a little bit of thermodynamics and statistical mechanics when you start getting into decoherence, but don't get bogged down there -- those topics alone can be a career. Electricity and magnetism nearly killed my interest in physics; I really struggled with Maxwell's equations in large part because I didn't understand partial differential equations yet. So, if you find yourself losing momentum(!) here, shift to a different approach and come back for the physics later. You'll be surprised how much of it seems easy, or even obvious, after a little perspective.
  • Feynman Lectures on Physics: available in a nice, online form, at least in English. (The paper edition has been translated into numerous languages, including Japanese and Russian.) Somewhat dated -- who does physics in feet, even in the 1960s? -- and perhaps the closest to "trophy" books of anything on this list, but the explanations of concepts are still as crystal clear as the day Feynman gave them.  Most of the topics above can be studied straight out of this set.
  • Crawford, Waves: Volume 3 in the Berkeley series, this is the one I learned from. Waves in 1, 2, 3 dimensions, standing waves, diffraction, propagation, all this just sits in the back of your brain once you've learned it and influences how you understand other ideas -- especially optics and quantum mechanics.
  • Hecht, Optics: I learned from an earlier edition of this, and use the current edition in my own group. For our stated purpose of making #QuantumNatives, perhaps the single most important physics topic and book; understanding interference patterns and waves in general is critical. I think you can do this without the Waves book above, but put them together and you have a powerful understanding.
  • French, Taylor, An Introduction to Quantum Mechanics: eventually, yes, you'll want to learn this: how spectra work, energy levels, atomic structure, bonding, wells and tunneling, etc. There are lots and lots of books on the topic. I learned from this one, but you can easily substitute here.
  • Saleh, Teich, Fundamentals of Photonics: I hesitate to even put this on the list; I have a copy but refer to it only very rarely, compared to the other books here. Most of what beginning engineers need to know is covered more than adequately in Hecht, but coupled with Hecht for fundamentals and the more abstract Gerry & Knight, the three books feel like a good set. I'd call this a low-priority acquisition and read, unless you're doing experimental work.
  • Gerry, Knight, Introductory Quantum Optics: I'm probably betraying my current preoccupation with quantum networks here, but I think this is a good topic that will aid in an understanding of quantum hardware more broadly, and this topic is surprisingly not covered in any depth at all in Mike & Ike. Perhaps optional, but I've found this valuable. In fact, though, I acquired it fairly early in my quantum career, and I initially found it rather opaque. As my skills have grown, though, I have referred to it more and more often.
  • Gershenfeld, The Physics of Information Technology: one of my favorite books. Not flawless, but where else will you learn about optical fiber, magnetic disk read/write heads, and semiconductor physics in one place? (Man, I'm citing a lot of books from MIT in this list!)

Cryptography and Security

Note that the security book probably belongs up under Computer Engineering rather than here, but I put it here anyway. If cryptography weren't such a juicy, well-funded topic for quantum computing, I might not have a separate section here, but in the context of growing #QuantumNatives, it's essential.
  • Bishop's Computer Security: Art and Science: security is a topic that far too many of us learn in an ad hoc fashion. This 1,400-page tome should help you realize that it's an important and rigorous field, and not something to be trifled with. Most universities will have at least one course on the topic, take it! Oh, and this book dedicates only about 10% of its length to cryptography itself, another indication of how broad and rich the concept of security is.
  • Schneier, Applied Cryptography: is there a better book than this out there?  It's now quite, um, mature, but it's so lucid, it's a classic. It also goes into more cryptographic corners than Bishop, including things like zero-knowledge proofs, and so might be a better fit for quantum folks than Bishop...if only there were a 3rd edition. The second edition is new enough to have a few paragraphs speculating about quantum computing, but old enough to just predate AES.
  • Menezes, van Oorschot, Vanstone, Handbook of Applied Cryptography: this one is definitely optional, I hesitated to even include it here. But if you want to go further into the field, there's a lot here that's hard to find anywhere else in such a comprehensive, organized fashion. Again, though, 20 years old.
  • Singh, The Code Book: a readable history of secrets, and more up to date than Kahn.
  • Kahn, The Codebreakers: 1,200 pages of goodness, if a bit of homophobia thrown in, which certainly occurred in the statecraft of spying through the years. Originally published in 1967, before public-key cryptography and the disclosure of Ultra; updated but not very effectively some years later. (See my review.)

Ethics and Society

I believe this is critical to the development of responsible, mature engineers, but I don't have a single, comprehensive, neutral point of view book for the reading list. Recommendations?
  • Peter Neumann's Computer-Related Risks. To the best of my knowledge, there's still nothing else like it. Peter is still the chair of the ACM RISKS Forum. If you don't have a healthy respect for what can go wrong with, and as a result of, computing technology, then you are Icarus incarnate. (The book is 1995, and availability is apparently limited; is there a more modern equivalent?)
  • Your Computer is on Fire: I found this book uneven, and I don't think it provides a well-rounded, comprehensive survey, but it's still probably the best book-length thing I've read on how technology influences and is influenced by human biases and problems. If you want to replace or augment this with something more on the ethics of computing technology, including race and AI, the surveillance society, etc., I am okay with that. Reading the news every day and thinking about its implications is necessary but not sufficient, IMO.
  • Failure to Disrupt: Perhaps the best cautionary tale I have read on computers and society, showing that technology alone is not enough. This might feel off topic, but I think everyone should be aware of the limitations of our ability as engineers alone to remake the world.
  • Something on the history of technology and how it has been used both for good and for bad, and how it is reshaping society.

Quantum Computing and Information

Finally, we come to the core topic itself, if you're aiming to be a #QuantumNative engineer. We've already seen Dancing with Qubits and Ultimate Zero and One above, so here we go deeper. There's actually quite a bit of overlap among these, but you'll find the varying perspectives useful. It would be nice to have a good one on hardware, and an up-to-date one on algorithms. Both topics are moving too fast, though.
  • rdv & satoh, Understanding Quantum Computers: not a book...yet. Broad-ranging and very introductory, this covers about twice the material of a popsci book, covering key ideas as well as some aspects of the business and some chats with important researchers. After working through this course, you'll be ready to tackle Mike & Ike.
  • Rieffel and Polak, Quantum Computing: A Gentle Introduction: until the advent of Dancing, this was the book I recommended for a first serious book on QC. It's still good. More on algorithms, less on background math and nothing on implementations and decoherence.
  • Nielsen & Chuang (or, Mike & Ike), Quantum Computation and Quantum Information: this is the book you must have on your bookshelf. Yes, it's now 20 years old, but it still hasn't been surpassed in comprehensiveness. (Perhaps it's impossible to have one single book on the topic now, like having one book titled "Computer Science".)
  • Kitaev, Shen and Vyalyi, Classical and Quantum Computation: A short and rigorous but remarkably clear book, I found this an excellent complement to Mike & Ike. It cleared up a lot of things I found opaque in Mike & Ike.
  • Preskill's Lecture Notes for Ph/CS 219: Preskill has a solid claim on being the best explainer in the quantum business. His chapters date back as far as 1996, and as recently as 2018. The explanation of entanglement is straightforward, provided you understand the notation. These chapters are free, as well as incredible content, and so are a great place to start before you begin stocking your shelves with expensive books.
  • Wilde, Quantum Information Theory: covers the theory of information -- given a certain amount of noise, how much information can a channel carry? The book covers classical channels (Shannon theory) well, before moving into quantum.
  • Asfaw et al., The Qiskit Book: A rapidly-evolving introduction to quantum computing using IBM's quantum computers and the Qiskit Python toolkit. Couple this with the other books here, and your gut-level feel for how quantum computers work, and how to design algorithms for them, will grow rapidly.
  • Aaronson, Quantum Computing Since Democritus: about a third of this is non-quantum computational complexity, so it will serve as our pure theory book. Very few equations, and some of Scott's quirky humor, but make no mistake, this is a serious, rigorous book.
  • rdv, Quantum Networking: hey, you got a better suggestion? In fact, the ten or so hours of video that makes up the bulk of our own course, "Overview of Quantum Communications", is now available on YouTube. With apologies, some of the materials such as quizzes and slide PDFs are still under lock and key, but we hope to make public a free text based on the course soon.
  • Lidar & Brun, eds., Quantum Error Correction: this being a collection of chapters from different authors, (the only such book on this list), and now also mature, it would be nice to have a more cohesive and up-to-date book, but I don't know of one. Lidar & Brun's introduction on decoherence in quantum systems is probably the best summary of the topic I know of, which is what tips the balance here instead of just recommending a research paper, regardless of how good it is.

The Freshman Short List

Okay, okay, all that's way too much. Where should I start? With a sigh and a heavy heart (I hate shortening lists), here is one book each to start with from the largest of the above categories (plus one more).
Note that I only included one math book. You can get surprisingly far into quantum computing with nothing more than complex numbers, summations, matrix multiplication, tensor products, and the rudiments of probability. Sutor has not a single integral in the book. But to move more deeply into quantum mechanics, as well as into Gershenfeld and into the nonlinear optimization of deep learning, you will need not only differentiation and integration, but also the basics of partial differential equations. You shouldn't let math intimidate you out of working in this field, but at the same time, you should never stop trying to learn more math.
Of this list, Hennessy & Patterson, Gershenfeld, and Mike & Ike are probably most commonly used as graduate-level texts. Certainly, you should be prepared before tackling each of them, but ambition will be rewarded with an accelerated arrival at the ability to discuss these topics at the highest plane, with professional engineers and researchers.
So, the Freshman Short List:
  • Sutor (488 pages)
  • Margalit & Rabinoff (??? pages)
  • Cormen & co. (1,320 pages)
  • Hennessy & Patterson (936 pages)
  • Hecht (720 pages)
  • Gershenfeld (388 pages)
  • Bishop (1,440 pages)
  • Mike & Ike (702 pages)
That's 5,994 pages of paper, plus the equivalent of several hundred more in interactive web pages. If you're already a budding programmer, a dedicated 10 pages/day will get you through those by the time you're a junior (10 pages might be 20 minutes or several hours, depending on the content, how much background work you have to do to understand the topic, and whether you diligently do enough of the homework problems). That would make an excellent goal.  If you're not much of a programmer yet, you'll move slowly through Cormen; learning how to extend from a few lines of code to understanding the abstractions in algorithms takes time and patience. (I think that's one of the biggest intellectual hurdles I have ever had to guide students through, and needs much more attention in CS/CE/SE education, but that's another post entirely.) There's no harm in taking your time, keep up slow and steady progress. And don't hesitate to ask questions.

Good luck -- and come join my group!

Revision History

  • 2020/5/26: First published.
  • 2020/5/27: Placeholder for SE added.
  • 2021/6/15: Added some words on ethics and society, but only a reference to Neumann's RISKS.
  • 2022/1/12: Added Failure to Disrupt and Your Computer is on Fire, and a link to our Intro to Quantum Communications videos.

Friday, May 22, 2020

3.3 Digging into the Cryptanalysis of IPsec

(See the previous installment or the top level of this series of posts.)

What is the recommended lifetime of an IPsec Security Association today?  This is the question that has proven to be so hard to answer, and that has led me wandering all across the web.  Probably the most relevant source is, naturally, the mailing list where most of the design work is documented.

One early, relevant message from 08 March 1995 carries the quote:

"I think 2^32 is a better bound than 2^43, at least for certain modes
of DES. For instance, after 2^32 blocks in CBC mode, you expect to see
two identical ciphertext blocks, say c[i] and c[j]; the difference
between their predecessors will match the difference between the
corresponding plaintext blocks, i.e.,
p[i] xor p[j] = c[i-1] xor c[j-1]
Information thus starts to leak after 2^32 blocks (square root of the
message space). I would recommend 2^32 blocks as the limit for the
lifetime of a key, and that takes care of the 2^43/2^47 attacks as
well."

referring, although not by name, to both the birthday paradox and the differential cryptanalysis limits discussed above.  Keep in mind that at $2^{32}$ blocks, we are at a 39% probability of there being at least one ciphertext collision revealing some information.

Searching the archives for "birthday" also turned up some relevant messages, e.g. the relatively recent (21 April 2015) message  quoting the earlier message:

"> I think the main problem with 3DES is not that it is significantly slower
> than AES, but that it has blocksize of 64 bits, that is considered
> loo small for high-speed networks, when the possibility of birthday attack
> leads to necessity to frequently rekey.
It’s hard to make that case. The blocksize is 64 bits. So it’s prudent
to not use more than, say, a billion blocks. A billion blocks is 64
Gb. There are very few real tunnels that run that kind of throughput
in under a minute. OTOH it’s no problem at all to run a CreateChildSA
every minute, or even every five seconds. So I think there are very
few cases that *can’t* use 3DES."

This is interesting, particularly given its newness.  The author (Yoav Nir, one of the long-time leaders of the IPsec community) considers 3DES plus very frequent rekeying to be sufficient, at least for some use cases, and it's important for backwards compatibility.  However, in a slightly earlier (2012) exchange on the mailing list, David McGrew (another key IPsec person) and Nir covered the same issue, with McGrew arguing that no more than 50 megabytes should be encrypted with the same key even using 3DES, due to the birthday paradox.  McGrew went so far as to write up a 16-page analysis posted on the Cryptology preprint server (see references for more).

Wednesday, May 20, 2020

Looking Forward to Ramen Again

I can't claim to know much about the best ramen joints in the country. I'm a fan, but have no credentials as a connoisseur. But I do have a few favorite ramen joints I'm looking forward to visiting again when things ease.
  • Tann-ya was probably the ramen joint that opened my eyes to the possibilities. It was also the first restaurant I ever knew of that had real-time online information about how long the line is -- being across the street from Tokyo Institute of Technology brings you a creative, technical clientele.
  • Ichikanjin here in Kamakura makes a original, fresh take on ramen: tou-nyuu (soy milk) with crisp, sharply-flavored fresh vegetables on top. Walking distance from our current house.
  • Yoshimura-ya, which anchors what we call "ramen intersection" in Yokohama.  Smoky flavor, and some fantastic, green not-really-garlic garlic, and a broth that you can watch being made in stages. The wait might be over an hour, so plan accordingly.  Has a Wikipedia page!
  • Soranoiro with vegan ramen, though I'm a fan of having the crisp-fried cheese with it.
  • Yabai Ramen is the opposite from Tokyo, but we'll go out of our way to eat there when driving through Odawara. (We've only eaten at Yabai, not its sister shop.)
  • Tinnun in Jimbocho is maybe the farthest from traditional -- it's Thai style green curry ramen. I'm always jonesing for this.  Gotta go to the Jimbocho restaurant, it seems the other ones in this small Tokyo chain don't have the goods on this.
  • Fuku-ya, a tiny local joint with good, well, they call it soba, but it's closer to ramen. Not a game-changer, but one of our local haunts. Their focus is about 50/50 on the noodles and on artisan sake they bring in from another prefecture, which interests me not at all. They're actually doing take-out during this episode, but we haven't ordered from them yet.
  • Ramen Jiro. Of course. 'Nuff said.
There are many websites in both English and Japanese dedicated to the art of ramen. I should check them out, but I think I'd wind up walking to Tokyo and pounding on some doors and begging.

3.2 IKE and IPsec

(See the previous section or the top level if you're wondering what this is.)

If you really want to dig into the key exchange protocol, RFC 7296 (Oct. 2014) is the most modern reference.  Unless you're actually manually configuring or implementing the stuff, you probably won't care about the differences between it and the older versions.

But you might want to start with RFC 4301 (Dec. 2005) (also a proposed standard), which is titled, "Security Architecture for the Internet Protocol."

IPsec has a couple of modes, but let's stick to what's called tunnel mode.  Two boxes, known as gateways, build one or more Security Associations (SAs). An SA describes which packets passing between the gateways are to be encrypted and how.  Those that are encrypted are encrypted in their entirety (packet headers and all), and sent as the payload of another IP packet, to be decrypted at the far end.  Tunnel mode is most often used to connect together via the Internet two networks (e.g., two offices of the same company) that are each considered to be relatively secure networks.  The packets between computers in one network and those in the other network are encrypted only during their transit from gateway to gateway.  Of course, these days, much (most?) data is also encrypted by the end hosts, especially for the two major applications of web and email, so much of the traffic in the tunnel will be double-encrypted.

The first SA created is the IKE SA itself, used only to carry the messages that govern the tunnel.  The first exchange of messages negotiates some security parameters, and carries random nonces used to "add freshness" to the cryptographic exchange and the parameters to be used for the Diffie-Hellman key exchange.  I believe this is where the preferred choice for the bulk encryption (3-DES v. AES v. whatever) is also negotiated.  Since we have not yet established the tunnel, these messages are necessarily sent as plaintext.

A block of material called SKEYSEED is calculated independently by both ends using the nonces generated by both ends and the shared secret generated by the Diffie-Hellman exchange in the INIT. Building SKEYSEED involves the use of a pseudorandom function (PRF) also agreed upon...in the first exchange?  I'm having trouble tracking where that's chosen.

SKEYSEED is used first to generate a key for the next message exchange, and then later to make keys for the Child SAs (below).

Next, there is an encrypted exchange that is used to authenticate the parties.  The authentication may be via an RSA digital signature, a shared (symmetric) key message integrity code, or a DSS digital signature.  In all three methods, each party signs a block of data using the secret, in a fashion that can be verified by the partner. (This could again be vulnerable to Shor's algorithm if it uses one of the public key methods, but keep in mind the messages containing this information are also encrypted; however, as we are just now
authenticating, it's possible that, up to this point, the partner at the other end of this connection is not who they claim to be!)

The IKE SA is used to create Child SAs, which carry the actual traffic.  The keys used for the Child SAs, therefore, are the obvious target for traffic-based attacks, though the real prize is the keys for the IKE SA.  I'm having a hard time imagining how to mount an effective attack against the IKE SA.

The key material for the Child SA is generated via a complex mechanism involving a new nonce and the PRF previously specified.  The initiator of the creation may also, optionally, specify that an entirely new Diffie-Hellman exchange be performed.  I'm very unclear on how often that option is used in practice.

Each SA, whether IKE or Child, can (and should) have a lifetime.  That lifetime can be specified in either seconds or in bytes that have been encrypted as they pass through the tunnel.  Once the lifetime has expired, the two gateways must create a new Child SA with new keys. This ultimately is the heart of what we're looking for here: what is that recommended lifetime today, and what should it be in the light of quantum computing?