Omnifora Politifora Freefora

Episode 0035: Cryptographic Hashes

(Omnifora) #1

Security Now!: Episode 0035 - Cryptographic Hashes

Audio

Alternative Link

Meta

Hosts Run Time Description
Steve Gibson
Leo Laporte
00:34:05 Having covered stream and block symmetric ciphers and asymmetric ciphers, this week Leo and Steve describe and discuss ìcryptographic hashes,î the final component to comprise a complete fundamental cryptographic function suite. They discuss the roles of, and attacks against, many common and familiar cryptographic hashes including MD5 and SHA1.

Extended

Attribute Value
SERIES Security Now!
EPISODE #35
DATE April 13, 2006
TITLE Cryptographic Hashes
SPEAKERS Steve Gibson & Leo Laporte
SOURCE FILE http://media.GRC.com/sn/SN-035.mp3
FILE ARCHIVE http://www.GRC.com/securitynow.htm
0 Likes

(Omnifora) #2

Transcript

  1. LEO LAPORTE: This is Security Now!, with Steve Gibson, Episode 35 for April 13, 2006: Cryptographic Hashes. Bandwidth for the TWiT Network is provided by AOL Radio at AOL.com/podcasting. Security Now! is brought to you by Astaro, makes of the Astaro Security Gateway, on the web at www.astaro.com.

  2. Time once again for our Crypto Primer with Steve Gibson. I have to say, Steve ñ welcome, first of all.

  3. STEVE GIBSON: Hey, Leo.

  4. LEO: I have to say I just have been really enjoying, and I know the listeners, too ñ the cryptography has been fun.

  5. STEVE: Been getting really good feedback, yeah.

  6. LEO: Yeah. You know, and whatís neat is Iím getting ñ you know, I published my public key on the show notes on TWiT.tv. And Iíve been getting a lot of people sending me encrypted email. Theyíre, you know, ìMy first encrypted email, itís so cool.î Itís just really fun.

  7. STEVE: Well, and in fact Iíve been preparing the questions for next weekís Q&A, our Mod 4 Q&A. And there have been some great questions and feedback thatíll be appearing in next weekís podcast, with people writing in with some questions theyíve had.

  8. LEO: Good.

  9. STEVE: So weíre on a roll.

  10. LEO: Every fourth podcast we answer your listener questions, so get them in so we can talk about them next week. Meanwhile, this week we continue with something called ìhashing.î

  11. STEVE: Yeah. This is another one of sort of our basic components of a comprehensive cryptographic suite. In the prior weeks, of course, to review very quickly, weíve discussed the two types of symmetric cryptography, stream ciphers and then block ciphers, where you use relatively short keys, that is to say, 128 bits is typical, sometimes 256. And you use a single key to very quickly encrypt or decrypt some content, where the same key is used to go both†directions.

  12. Then in last weekís episode we talked about asymmetric cryptography, also known as or popularly known as public key cryptography, the idea there being that you have different keys, one which you can let the world know about if you want to, and one which you keep private. The cool thing there is that many very powerful concepts become possible where youíre able to say, okay, anyone who wants to send me something, use my public key. Only I, who have my private key and keep it private, will be able to decrypt it. And the reverse is true. I could encrypt something that I wanted to send someone, and they would know it was from me if they used my public key to decrypt it.

  13. LEO: Thatís what weíve been doing. In fact, thatís what people have been doing. Theyíve been sending me encrypted email because they have my public key, and I decrypt it and read it. And then, you know, whatís fun is, because these key exchange servers, PGP and many other institutions and universities run these servers, I can go out, search for their key, and encrypt it back to them. And then once weíve exchanged encrypted email, itíll be encrypted from then on, which is great. Itís just very transparent and easy to do.

  14. STEVE: Very cool.

  15. LEO: Yeah, I really like it. You donít use this, though.

  16. STEVE: I just havenít the need. Itís funny because there was some discussion in our newsgroups about the fact that I had said, yeah, Iíve never been a PGP or other user. And some people were saying, wow, I find that really strange for, you know, a big security guy like me. But the fact is, I donít know why, but I just havenít had electronic conversations. I mean, I have a corporate attorney, but I go to his office, and I sign paper documents. Iím not doing this stuff over the air.

  17. LEO: Well, I donít, either. I have really no practical use for this. But itís just ñ well, there is one practical use, and thatís the cryptographic signing, which we havenít really talked about yet. But, you know, because people will spoof my name ñ and itís very easy to spoof email…

  18. STEVE: Oh, yeah.

  19. LEO: …and as a public figure sometimes people will spoof your name, I sign all my mail. So if you get mail from me thatís not signed, itís not from me.

  20. STEVE: Okay.

  21. LEO: So thereís a good reason to do it.

  22. STEVE: And in fact signing is one of the things that we cover today because signing uses hashes, so-called ìcryptographic hashes.î

  23. LEO: Right.

  24. STEVE: Okay. So getting on to todayís topic, cryptographic hashes. Theyíre known by many different names, sometimes called a ìcompression functionî or a ìcontraction function,î popularly known as a ìmessage digest,î sometimes called a ìfingerprintî or a ìcryptographic checksum,î also known as ìmessage integrity checksî or sometimes ìmanipulation detection codes.î Many different names.

  25. LEO: These things have more pseudonyms than Mata Hari. I mean, this is very ñ but itís all the same.

  26. STEVE: Well, yes. Those are all sort of the same. Some of the terminology, like ìfingerprintî or ìmanipulation detection code,î sort of talks a little bit about ñ it implies the application that youíre going to be using. But in every case these are reducing the amount of information typically to a much smaller size, which is really why ìmessage digestî is one of the more common terms. A digest, as we know, like ìReaderís Digest,î that takes a long book and reduces it to a shorter form, or a digest that appears at the beginning of a lengthy paper that just explains what itís about, sort of, you know, a capsule summary.

  27. The idea is that a cryptographic hash takes a long, typically long object in plain text ñ and in this case actually the term is ìpre-image.î In hashing terminology it is normally the same as the plain text, but technically itís called the ìpre-imageî versus the ìhash value.î So you take this pre-image that, for example, is email that youíre sending to someone, and you run it through an algorithm, much as weíve been talking, I mean, this is all about algorithms, of course. We had symmetric algorithms and asymmetric algorithms. Those were ciphers. And in all of the cases so far theyíve been reversible, that is, the only point to encrypting something is to decrypt it later.

  28. Well, now weíre running across something that is not reversible, and itís specifically the non-reversibility of it that is key. So we take our plain text or so-called ìpre-image.î We pump it through this cryptographic hash, and we get out something smaller, basically a token. And these are normally 128 bits, in some cases 160 bits, and even more recently longer tokens, 256 or 512 bits or more. But the idea is that that represents a fingerprint of what you fed in. That is to say that, if you change anything about the source text or the source content that is fed into the hash, you get a completely different output. And in fact, well-designed hashes, if you change ñ say that you had a 10K blob that you were going to hash. If you change one bit of that input anywhere, one bit, on average about half of the bits will change in the result. So, I mean, it basically takes a really large object, much larger than the result, and scrunches it down. And the point of this is, this is not reversible. Now…

  29. LEO: Is this somewhat like a CRC?

  30. STEVE: Well, itís a CRC except ñ CRC, by the way, stands for Cyclic Redundancy Check. The problem with…

  31. LEO: Itís a way of generating a number, a fairly large number, but a number that represents the data that youíre looking at.

  32. STEVE: It is, but itís a special number. And a CRC is a good example of what a hash is not because itís very easy to deliberately create some input which will result in a deliberately chosen CRC, that is, a CRC is not cryptographically strong because youíre able to say this input will give me this output. So if you wanted, for example, to create a different input that will produce the same output, that would be easy to do.

  33. LEO: Okay. So you could change a message in such a way that it would give you the same CRC, but of course would be†different.

  34. STEVE: Exactly. And thatís where a cryptographic hash is special. A cryptographic hash has three main focuses. First is, it is very easy algorithmically to come up with a hash of an input text. It is very hard ñ and by hard we mean in cryptographic terms, you know, millions of millennia kind of hard ñ to go the other direction, that is, to design an input that will give you a chosen output. That is, I mean, basically itís like itís a random number, but itís really not. I mean, itís a deterministic function. You put in the same text; youíre going to get the same hashed value. But it is cryptographically difficult ñ meaning really, really, really, really difficult ñ to design a text input that will give you an output that you have deliberately chosen. Itís just you put stuff in, and you get out this magic token, but thereís no way to design what youíre going to put in to get a specific token.

  35. LEO: Right.

  36. STEVE: And then the third principle of a hash is that there is no collision, that is, given two inputs, the probability of them hashing to the same result is really, really low. Youíre not going to get whatís called a ìhash collisionî with, like, a trivial change to an input is going to give you a huge output change. So…

  37. LEO: I mean, hashing is well known, has been around in computer science for a long time. How is a cryptographic hash ñ or maybe youíre going to get to this ñ different from just a regular hash?

  38. STEVE: Well, okay, hereís a perfect example. Say that I wanted to take everybodyís IP address ñ we know that IP addresses are four bytes, and weíve talked about the XOR function before. Say that I wanted to hash an IP address from four bytes down to one byte so that, for example, I wanted to, like, sort users to my website into 256 categories based on their IP. I could simply take the four bytes of their IP and XOR them together to give me a hash. And that would actually be a very nice hash because it would generally spread all the 4 billion IPs equally across just 256 results. So simply XORing the four bytes together. But itís not a cryptographic hash because I could look at someoneís IP and trivially see what itís going to be. And I could easily design or choose IPs that would hash into a given result.

  39. So hashes normally take some larger value and reduce them to fewer number. And good hashes will evenly distribute that reduction across their smaller space. Whatís special about a cryptographic hash is that you canít choose what youíre going to send it in order to get a known result. And you canít go backwards. For example, if I hashed ñ just using the little XOR example I gave, if I were to hash that from an IP address down to a result, I could easily spit out all kinds of IP addresses. That is, I could easily reverse that process and come up with IPs that are going to give me my final resulting hash. You cannot do that, thatís specifically what you cannot do with a cryptographic hash.

  40. LEO: Okay. Okay.

  41. STEVE: Okay. Now, one of the ways this is used is signing documents. And this is what weíve talked about before is you take a piece of email. Now, we know that we could encrypt the document in order to make it secure and send it somewhere. But say that we didnít want to encrypt it, we just wanted to say, you know, as in the example youíve given earlier, you know, Iím Leo Laporte, I really wrote this piece of email.

  42. LEO: And it hasnít been changed since I wrote it.

  43. STEVE: Well, exactly.

  44. LEO: This is very important.

  45. STEVE: Exactly. So what you do is, the PGP system youíre using, for example, it will literally do ñ it will take a hashing function exactly like weíve talked about, run your email through it, and produce basically a fingerprint of the document. So it says this is the result of hashing this longer email down. And itíll be 128 bits or 160 bits, depending upon what the hash is. And it says, you know, this is the fingerprint. Now, the problem is, if you just put the fingerprint at the end, somebody else could, in fact, change your document in some way, do a hash and change the fingerprint.

  46. LEO: Just paste a new one in.

  47. STEVE: Just paste, exactly, replace the fingerprint as they have changed the document. So the final key here is, this is where our public key cryptography comes in again. You encrypt just the fingerprint, using your private key that nobody else has.

  48. LEO: So not only does this say this is the hash for the message, but only I could create it.

  49. STEVE: Only you, using your private key, would have been able to encrypt that fingerprint. Thatís what gets appended to the message. Now the message gets sent to somebody else. And anyone who wants to can read it because the message itself was not encrypted. But to prove the authentic signer of the message, they would take your public key and decrypt the appended fingerprint using your public key. And that would give them the hash for the message. Then they perform the same hashing function you did and compare the hash they get with the hash that they decrypted from what you provided. Only if these documents are identical, that is, the one you originally signed and the one they received, only if they are absolutely identical will the hashes match.

  50. LEO: Just so people understand from a practical point of view, if you get email from me or anybody whoís using this, itíll be plain text email. You could encrypt it, but that would be another thing to do. This is just signed. Youíd get a plain text email, but at the beginning and the end it says, you know, ìPGP signedî at the beginning, and at the end it says ìBegin PGP signature,î and thereís this gobbledygook which is the cryptographic hash. Now, you could just see that and say, okay, fine. But in order to really verify that that came from me you would need to have PGP or what I use, which is the GNU Privacy Guard, an open source free one, installed. And then youíd need to get my public key to verify. Right?

  51. STEVE: Correct.

  52. LEO: And it does that automatically. But if you donít have my public key, you canít verify it.

  53. STEVE: Right. So I donít mean to imply that these are complex things that the user has to manually do.

  54. LEO: You know, the softwareís very good at this, yeah.

  55. STEVE: Exactly. If they were all set up to be doing this automatically, then it would just be, you know, it might just say ìauthenticated,î you know, automatically in their†system.

  56. LEO: Well, I mean, I have to say it is automatic, but thatís one of the complaints people have about this whole thing is it is so ñ itís not as easy as it ought to be, you†know.

  57. STEVE: Right.

  58. LEO: Momís not doing it. It does require a little geekiness. You have to install the software, which is not always easy. You have to know about keys and know that you have to get a key, and you have to be able to search the key server and all of that stuff.

  59. STEVE: Well, and my complaint, frankly, is that Iím not worried that somebodyís sending me stuff that you havenít sent me, yet every piece of email from you has all this extra crud in it, you know…

  60. LEO: Well, itís not that much crud.

  61. STEVE: …thatís visible in your email. So…

  62. LEO: Right. Well, thereís another way. If you certificate sign, then it would just send an attached certificate. Same idea, but itís not visible in the body of the email.

  63. STEVE: Right.

  64. LEO: I prefer to use the text method because itís more†universal.

  65. STEVE: Well, now, one place that many people who are Internet users may have seen a cryptographic hash is in download sites, which will often post the MD5 and/or the SHA hash for the files that are being downloaded. And this is sort of an interesting, you know, real-world practical example that people may have run across before because the idea being that ñ and a lot of open source sites will also do this. They will say, hereís our files, and hereís the MD5 of it, or the MD5 hash, or whatever theyíre going to call it specifically. The idea being then that this is them saying that this is ñ basically itís the fingerprint for the file. You download the file and then, using your own MD5 or SHA-1 hashing tool ñ and all operating systems have these as freeware, theyíre easy to find on the ëNet ñ you then give your own hashing tool that file, which will quickly produce, basically, the fingerprint. And there you just do a visual comparison. You look at the website, and it says, you know, 5A30FE1…

  66. LEO: Itís long, yeah.

  67. STEVE: …and you just visually compare that the result these people got when they produced the fingerprint is the same thing that you got when you produced it. And that tells you beyond, you know, with absolute certainty at a cryptographic level that that is, bit-for-bit, the identical file that they intended you to receive.

  68. LEO: Now, you know, a lot of programs do it. But Iíll tell you, the time when it really is important is when you are first installing PGP or GNU Privacy Guard, to make sure that youíre not installing some Trojan horse thatís posing as those. Because that would then compromise your security from then on.

  69. STEVE: Sure.

  70. LEO: Yeah.

  71. STEVE: Well, now, there is one really interesting trick to this whole thing, and that is about the bit-length because, you know, these hashes are long in terms of bits. I mean, obviously weíre used to talking about long bits. But there is an interesting and, I think, really sort of fun and fascinating attack on signed documents. If the person generating the document has no control over what theyíre signing, then theyíre not vulnerable to something thatís known as the ìbirthday attackî on hashing. But say, for example, that somebody wanted to trick somebody into signing a contract that was not in their favor. It turns out that itís easier to do than you might expect.

  72. First of all, letís step back a little bit. Thereís a well-known sort of statistical surprise known as the, what is it, the birthday puzzle or…

  73. LEO: Oh, yeah, yeah.

  74. STEVE: …birthday ñ the idea is, the question is, how many people would have to be in a room for one of them to have the same birthday as you?

  75. LEO: No, two people to have the same birthday. Not necessarily as you.

  76. STEVE: I know, I know.

  77. LEO: Okay, okay.

  78. STEVE: Iím doing this on purpose.

  79. LEO: Oh, all right.

  80. STEVE: So how many people have to be in the room to have the same birthday as you? Turns out thatís a lot of people. And remember, of course, we have 365 days in the year. So it turns out that you need 253 people in the room for the chance to be greater than 50/50 that one of them will share your birthday.

  81. LEO: That makes sense. That makes sense.

  82. STEVE: It does. It sounds about right.

  83. LEO: And if it were 365 people, it would be almost a certainty. Well, maybe not.

  84. STEVE: Well, no, because they might have a common birthday.

  85. LEO: They might have duplicates; right. Thatís right,†yeah.

  86. STEVE: But it turns out that 253 is the magic number of people where itís more than 50/50 that theyíre going to have the same birthday as you. The surprise is when you ask the question, how many people do you have to have in the room for any two of them to share the same birthday, and there the number is 23. And the reason is, if you have 23 people, you have 253 pairs. So itís the same 253, but instead of me insisting that someone have my birthday, itís, okay, whatís the chance of a birthday collision?

  87. LEO: Right.

  88. STEVE: And thatís the key, the birthday collision between any two people. It turns out that the same kind of thing can be used in order to create fraudulent fingerprints using one-way hashes, using cryptographic hashes. The way that would work is, say that I was hashing, and I had a hash that only produced a 64-bit key. Well, Iím saying ìonly.î But, I mean, 64 bits, thatís a lot of keys. Since 32 bits is 4†billion, which is to say four with nine zeroes, 64 bits is that many squared. So thatís going to be 16 billion billion possible hashes, which is to say 16 followed by 18 zeroes. Okay, I mean, thatís just a lot. So the chance ñ say that you only had a hash with 64 bits. The chance of two different contracts having the same fingerprint, the same cryptographic hash, would be one in 16 with 18 zeroes. I mean, just diminishingly small. Thereís just no chance youíre going to have, like, a good contract and an evil contract that are going to have the same hash.

  89. But if youíre able to prepare both contracts, you could make small changes to each of them, like adding a space at the end of a line or putting two spaces after a period. That is, you make tiny changes to both of them, checking to see whether they have the same keys. That is, itís very much like the birthday attack, where youíre not saying I want my evil contract to match the fingerprint of my good contract. Instead youíre saying Iím going to make a bunch of different evil contracts and a bunch of different good contracts. And Iím going to look for any collision of the hashes between them. And it turns out that is far more probable.

  90. LEO: Really.

  91. STEVE: Just like having many people in the room comparing their birthdays, where anyone who has a birthday collision gives you success. What this allows you to do, for the same reason of much lower probability ñ Iím sorry, much higher probability of the collision occurring, this allows you to prepare two contracts, a good one and a bad one, where theyíre going to have the same fingerprint. So say that I produce two contracts like this. I then get someone to cryptographically sign it. Later I can come along and claim that they signed the evil contract because it has the same fingerprint. And any judge who understood cryptography would have to accept the fact that the evil one was signed.

  92. LEO: Wow.

  93. STEVE: And it turns out that the number you need is half of the bit length, that is, 2 to the 32.

  94. LEO: That still seems a lot.

  95. STEVE: Thatís 4 billion. But it turns out that, since youíre just doing a forward hash, and youíre making small changes each time, it doesnít take that long to produce that many different contracts. And the chance is greater than 50/50, if you do that with both of them, youíre going to find a collision and be able to produce basically a fraudulent hash. And thatís why hashes are much longer than that. Thatís why theyíre 128 bits or 160 bits and even more now because it turns out, if you have control of both sources, then there is this chance for being fraudulent. Now, this is, for example, not a problem downloading a file because no hacker will have produced the good file and a bad file unless, you know, they were really, really clever. But in any case these hashes, even the smallest hash in common use today is 128 bits, which means you would have to produce 2 to the 64 sets of hashes of the good file and the bad file, 2 to the 64. Now weíre back up at, you know, 24 zeroes on the end of the number. So weíre really safe.

  96. LEO: People might say, well, even the 4 billion sounds like a lot. But with computers ñ itís not 4 billion, first of all. But with computers you can do this quite quickly, I would imagine.

  97. STEVE: Right.

  98. LEO: Itís a form of brute-force attack.

  99. STEVE: Right.

  100. LEO: Wow, thatís interesting. I didnít know that.

  101. STEVE: So, yeah, itís an interesting way that what looks like a very secure hash can be defeated, if you have control over generating both the good and the bad. There is, you know, because of this birthday collision there is a chance to, I mean, still itís a huge amount of work. But if the hash is too short, you end up needing less work than you would expect. So you just need to make sure youíre using long hashes. And everything today does.

  102. LEO: So, Steve, thatís why thereís so much gobbledygook at the end of my messages. And I donít want to hear any more complaints about it. Itís for security. Does it really bug you that all that stuffís in my messages?

  103. STEVE: No, no. I tune it out.

  104. LEO: You tune it out.

  105. STEVE: I tune it out.

  106. LEO: But fortunately, if you have the right software on your computer, it doesnít tune it out, and it says ìVerified. This came from Leo.î

  107. STEVE: So this is the final piece of our puzzle. Thereís really no need to spend a whole episode talking about cryptographic random numbers. Weíve talked about the idea of the need for generating really random numbers. For example, we mentioned it last week when we were talking about choosing a really good random number or pseudorandom number, unpredictable, unguessable at least, and then using that as your symmetric key for your bulk encryption, and then using public key cryptography to encrypt it, in order to allow a non-secure channel to deliver that encrypted symmetric key and then decrypt it. So basically weíve got symmetric block ciphers. Weíve got asymmetric block ñ Iím sorry. Symmetric block ciphers, symmetric stream ciphers, asymmetric ciphers which are block ciphers, cryptographic hashes, and cryptographic random number generation. Thatís sort of the suite of our fundamental algorithms that allow us to do all kinds of cool stuff. And week after next weíre going to look at all the different ways these five building blocks can be pieced together in order to solve all the common problems of cryptography.

  108. LEO: Itís really fascinating. You know, itís kind of spy stuff, and yet itís very practical. And itís kind of elegant and mathematical, too. Itís really been fun.

  109. STEVE: And anybody who uses the web, you know, now you know what the MD5 is when you see them on download sites. And anyone who establishes a secure connection to a server is using symmetric and asymmetric ciphers. In fact, those certificates are signed ñ and weíre going to talk about certificate signing week after next, after next weekís Q&A episode. And, you know, itís using hashing in order to put all this stuff together.

  110. LEO: So cool. So neat. Wow. And so next week we will do the question-and-answer session.

  111. STEVE: Yup. Number 36.

  112. LEO: And then weíll be back and talk a little bit about practical applications, which is always fascinating, too. But now you have the fundamentals.

  113. STEVE: We have all the building blocks in place.

  114. LEO: I want to thank our good friends at Astaro for ñ and I mispronounced their name last week, and I apologize. Astaro.com, Astaro Internet Security, their hardware and software solutions. And by the way, donít forget there is a free version for home use to protect up to 10 IP addresses. And this is very cool. Basically itís open source. You can add it to an old PC, put a second Ethernet card in, and youíve got an industrial-strength, stateful packet firewall. Youíve got VPN for both PPTP, the Windows VPN, but also IPSec. You get intrusion detection and protection. And you can even add a very powerful AV and content and spam filtering for as little as 79 euros a year. Itís all free, but then the antivirus on top of that. For more information, www.astaro.com. And thanks to our friends at America Online for providing us with the bandwidth for this podcast, of course AOL.com/podcasting. For more information about the topics we cover on Security Now!, visit Steveís site, GRC.com/securitynow.htm.

  115. Somebody said, ìIím confused, thereís two show notes.î I put some links sometimes on my page. But really the main show notes are on your page, Steve. Thatís where youíll find also transcripts, 16KB versions for the bandwidth-impaired, and letís not forget SpinRite, which really is Steveís sponsor.

  116. STEVE: It is. It is the sponsor of GRC and my website and our bandwidth and all my time, yeah.

  117. LEO: Keeps him in ham sandwiches. So if you have a problem with your hard drive, itís the ultimate disk maintenance and recovery tool. SpinRite.info for testimonials. GRC.com is the other place to go. And thatís a good place for ShieldsUP!. And youíre still developing, I know, your freeware, your security freeware like DCOMbobulator, UnPlug n’ Pray. Youíve got a new one in the works, donít you?

  118. STEVE: Actually Iím working right now, Iíve been coding all week. GRC will shortly have a brand new feature, the first brand new feature sort of service that weíve offered in years. Itís something Iíve wanted to do. And in fact, Leo, Iím getting it ready because I want to introduce it on the ìCall for Helpî show up in Toronto next week.

  119. LEO: Oh, cool.

  120. STEVE: Or week after next, rather.

  121. LEO: Good. So watch ìCall for Help,î if youíre lucky enough to be able to get it. Otherwise weíll mention it.

  122. STEVE: We definitely will in two weeks, yeah.

  123. LEO: Yeah, yeah. Thanks, Steve. Weíll see you next week for our Q&A segment.

  124. STEVE: Great.

  125. LEO: Iím Leo Laporte. Thanks for joining us. Weíll see you next Thursday on Security Now!. Security Now! is brought to you by Astaro, makers of the Astaro Security Gateway, on the web at www.astaro.com.

Files

:copyright:

Copyright © 2006 by Steve Gibson and Leo Laporte. SOME RIGHTS RESERVED
This work is licensed for the good of the Internet Community under the
Creative Commons License v2.5. See the following Web page for details:
http://creativecommons.org/licenses/by-nc-sa/2.5/

0 Likes

(Omnifora) #3

Links and Other Materials

Sponsors

0 Likes

(Omnifora) #4

This Post Is Reserved

0 Likes

(Omnifora) #5

Episode Wiki

This is an episode-specific wiki post. It may be edited by anyone.[1]

Please add only episode-relevant information.


  1. Anyone with sufficient privileges. ↩︎

0 Likes