Probably? I'll grant you that the output of SHA-512 is going to be longer than combining several small hashes, but I don't intuitively see that it's necessarily more secure.
See Joux's work on multicollision attacks. While it was thought (before he developed this attack) that taking a (secure) N-bit hash and a (secure) M-bit hash and concatenating the outputs was equivalent to a secure (N+M)-bit hash, it turns out this is not the case - it's more like a max(N,M)-bit hash, for (some) security purposes, such as collision resistance.
It's not intuitive, though - at least not until after you see the attack. We had been designing and using hashes based on the Miyaguchi-Preneel and Davies-Meyer methods for well over a decade before Joux noticed the problem.
The thing that really makes me want to stay away from Microsoft software (and proprietary software in general, though Microsoft seems particularly prone to it) is exactly this sort of behavior. For a long time I've had the sentiment that Unix was more secureable than Windows (securable, not secure-out-of-the-box, since neither of them is that), precisely because I find it much easier to look at a Unix system (particularly one which I have the full sources to) and understand what it is doing than I do when using a Windows system.
I assume this is actually undocumented behaviour, since I haven't seen anyone claim to have known about it before now, nor can I find any references on MSDN about it. Having unintuitive and undocumented behaviour is exactly the sort of thing that makes it very hard to gain a correct mental model of how a system behaves, and if you don't even understand how the system works I don't see how one can secure or troubleshoot the system in a way that isn't essentially "shotgun debugging".
New users are led to believe they can take hardware compatability for granted as they did with Windows
In my experience, assuming anything is compatible with Windows is also a bad assumption. Sure, you'll almost certainly be able to get a driver, but there is a reasonable chance that it's a complete POS that will make your system stupidly unstable, will never be updated once the hardware is no longer sold (or once the vendor is bought or goes out of business or changes product focus or whatever), and at some point you'll do a patch install and it will suddenly stop working. Overall I find driver _quality_ to be much better on Linux than on Windows -- with the notable and serious exceptions of video card drivers (and of wireless cards up until a couple of years ago).
Of course most of the larger/better manufactuers have quality Windows drivers, but then again that is exactly the space where the Linux drivers are also pretty strong (never had driver problem on either platform with, say, an Intel E100 NIC, or an SB Live).
Funny how you never really hear about the applications written in COBOL, Fortran and PL/1 crashing.
Not really. They were probably written 20 or more years ago, there has been plenty of time to catch most of the bugs. Not a function of language, techniques, or skill, just time and use. And stuff written in COBOL and PL/1 probably doesn't get touched much, so no new bugs.
I'd love to see some uptime numbers for past systems versus the systems we have today. I wonder if they'd show the downward trend that I suspect they would.
On average, sure. Most servers don't stay up for more than a few months, a couple of years at best. But they also cost a lot less than an S/360 did in 1965. You want a box that will stay up, buy a Tandem or something.
As anyone who's tried out x86 Solaris is aware; it's no match for Linux on the platform - or any other platform other than Sun's own hardware for that matter.
Even on Sun hardware, Linux or *BSD can be a win. Sure, on an E10K Solaris will be faster than Linux, but on an SparcStation or early Ultra, Solaris is not that snappy. I would like to have a Sun box fast enough to run Solaris on, to keep current on Solaris administration, but on my current Sun machines it's not worth it.
KAI C++ is basically dead (Intel bought them a couple years back, which sucks, as KAI was about the best C++ compiler I have seen), and I'm not totally sure about Compaq's Alpha compiler, but it looks like the SGI Pro64 compiler is still alive (and GPL'ed now... interesting).
Isn't this in line with the whole "No machine[usually meaning computer, but in this case a jumpdrive] is secure if the physical box is in the hands of the hacker/criminal."
Yes and no. There are devices which are designed to remain secure even in the hands of a high-level attacker with major resources, and destroy their keys if they detect they are being tampered with. Mostly used by banks and the military, as it's very expensive to build all the countermeasures in. One nice one is the IBM 4758, which IIRC runs for about 10K a pop. The IBM 4758 actually has a protocol error that lets you attack it without breaking through the physical protections, but no reason a system with a 'fixed' protocol set couldn't be built.
But due to size and cost, no way you can build countermeasures like that onto a jumpdrive.
- Voice controlled robots ("You missed a corner, vacuum cleaner") - Data search by voice ("Find me a channel that plays Star Trek")
Kinda jumping ahead of yourself, aren't you? There are two steps to an operation like these, speech to text, and understanding the text you get out. Speech recognition gives you the first part, but you still have to be able to pull apart the sentence and figure out what it means.
Also, the article didn't say more accurate than software, it said more efficient. You know, uses less power and stuff like that? If the applications you mention (like search via voice) were possible/usable, you could run them today on an upper-end PC no problem.
I guess I just don't understand why the MPAA's members would rather sit around and piss and moan about piracy instead of trying to defeat it. It's not like it's impossible to make a good deal of extra money off of it.
Control. They would rather have 99% of a market worth $10 billion than 50% of a market worth $100 billion.
Just what I wanted. (Disclaimer: I haven't seen these particular movies, so perhaps they are better than I'm guessing based on ROTJ.)
I remember liking them when I saw them on tape when I was around 8 or so. Of course, I was 8. I remember being sort of freaked out by the giant spiders (they dined on Ewoks), but I suspect if I saw any of them again I wouldn't be terribly impressed.
I wasn't there this year. A friend told me that the embarrassing thing was that the Chinese paper was REJECTED from the conference. They presented their results at the rump session.
Of course, it would have helped the paper's chances of being accepted if:
a) They had actually presented the methods they used
and/or
b) The results had been correct. Initially, they were not finding collisions for MD5, but what they *thought* was MD5 (due to a translation error).
So what the reviewers read was a claimed attack on MD5, with no details, and their examples did not work. If I were reviewing that paper, I would have rejected it too. They didn't correct the paper until (IIRC) the day before the rump session.
If, after a nuclear war, you spend your time hunting for Planck's Constant (or server documentation) instead of food
There are non-nuclear EMP devices, you know. Also, to quote from the link the grandparent provided:
"A large device detonated at 400-500 km over Kansas would affect all of CONUS. The signal from such an event extends to the visual horizon as seen from the burst point."
Usual airburst detoniation for an ICBM (at least from what I found on Google) is in the 4-20 km range. That is to say, once could take out a lot of computers while causing relatively little physical damage.
Now the neighbor's kid can activate my credit cards he stole from my mailbox without breaking into my place to use my phone line.
A lot of the CC companies don't bother checking anyway. Last time I activated a card, I did it from a friend's landline, as I spent a few (rather nice) years without a phone of any sort, and I had no trouble at all activating it.
and a K&R C compiler - and not a "modernized" just-pre-ANSI one either, I mean something that choked on function prototypes in a way my Sinclair QL's Metacomco C compiler didn't back in 1995...
In case anyone's interested, this is a HP-UX 11 (the machine is a 9000/800) system
That C compiler is (AFAIK) only shipped for building new versions of the kernel. You can also buy a reasonably decent C99/C++98 compiler from HP for about a zillion dollars. The reason they cripple the shipped compiler is to force you to buy the real compiler (or install GCC, of course). So HP isn't really a K&R only system (I mean c'mon, how could you sell a system like that anytime in the last 10 years?), it just ships with a crippled compiler, which is a shame because some people continue to insist that it's usable for anything -- it's not.
Basically a EAL or Orange book certified system will not allow casual transfer of data from a higher security level to a lower security level. That is the core of the qualification concept. All the stuff about admin roles, etc is just fluff oriented towards managing the concept and the granularity to which it is managed.
Ummmmmm... no. Multilevel security was only a requirement in the Orange Book of level B1 or higher. C1/C2 evaluated systems did not need any sort of MLS. There are Unix-based MLS systems (Trusted IRIX was evaulated at either B1 or B2, IIRC), but they are not common, and generally pretty painful (an attribute shared with all other MLS systems). In normal Windows or Unix systems, there is no labeling of data, there are nwhich would be kind of a waste of money, but hey.o controls preventing you from sharing information with other users, none of that. And for good reason - MLS is about information control, while people generally get work done by *sharing* information. The only people who want MLS are the military/intel groups, and from what I've heard, most of the people using it there don't like it much either.
As for CC, there is absolutely no requirements whatsoever in terms of protection. With the right proection profile, you could probably get MS-DOS to EAL2 at least. In this case the profile would say "this OS doesn't do anything security-wise", and then the evaulation would prove that this protection profile was correct.
Also, it's Aleph1, not Alef1. Hebrew letter (or, in this case, a Hebrew letter + number, specifying a transfinite number)./tangent
(1) If we're so stupid we can destroy the only planet we live on, I don't see how we're doing the universe a favor by spreading.
If we had self-sustained colonies on other planets, wouldn't this mean we weren't blowing up the only planet we live on when we finally get around to blowing up the Earth? Because, you know, we would have those other ones.
I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.
The whole point of evaluation/audit is that the people who check the code are not the people who wrote it. That's why if you want a CC or FIPS 140 evaluation, you fork over half a mil or more to a testing lab.
My understanding was that this is not true. At best you get the square root of the number of steps that would be required for a non-quantum brute force search. This means that key sizes are effectively halved, but that isn't an insurmountable problem.
Bingo. Which is why the AES competition required support for 256 bit keys, when even 128 bits is out of reach by any conceivable technology.
Factoring is one such case, which is why quantum computing spells the death of RSA.
Not true, necessarily. Shor's algorithm is algorithmically faster than the generalized number field sieve, but there is a constant in there. We don't know how big that constant is, and we won't until we have a quantum computer big enough to run Shor's algorithm (30 qubits or so, IIRC). It's entirely possible that Shor's algorithm is only faster then the GNFS once you hit keysizes of 10,000 bits, in which case it doesn't matter. OTOH, if Shor's algorithm is faster than the GNFS on 256 bit keys, we are, indeed, in some trouble. Of course running Shor's algorithm on a 1024 bit RSA key would take quite a large quantum computer, too.
And, as you mention, there is no algorithm for compute discrete logarithms much faster than usual on quantum computers. I haven't heard about such an algorithm, anyway. Doesn't mean it doesn't exist, of course.
Summary: algorithmic complexity is not the sole determinant of algorithm running time.
In summary, quantum computing is powerful, but not a magic wand that makes all classical encryption schemes invalid.
Thank you. Every time a quantum crypto or quantum computing store pops up here, the hype level seems to increase by several orders of magnitude. It's really annoying.
From article: And thanks to a 10-year technology pact, Sun's servers will be certified to run Windows.
Ummmm... what the fuck? I've got to assume this is just plain wrong, since it seems to imply either that MS will be porting Windows to SPARC, or that Sun is dropping SPARC, or something like that. Maybe they just mean the Opteron and x86 based systems? If so, not exactly a huge deal, especially considering that Sun's x86 stuff is just the same as stuff you can get from HP or Dell, just with a Sun logo.
However, at one point, sooner or later, you need to pickup the cheque or cash. Wire transfers can be traced, as can direct deposits. If there's a cash-only transaction, the cash can be marked and the police can watch the drop point.
At least until we finally get a practical electronic cash system set up. Untraceable and unforgeable. "You will post $10,000 worth of electronic cash certificates to alt.test.messages, encrypted with this (throwaway) PGP key on this date".
Of course given that we've known how to build one for over 15 years and still nobody is using one, it seems the economic and social problems far outweight the technical ones on this issue. IIRC some of the core patents expire pretty soon, maybe that will spur something on, but I kinda doubt it.
not sure you are allowed to ask that in an interview.
You're not. Or rather, you can, but it opens you/your company up for a lawsuit. Standing rules at my work for interviewing: no questions about wife, children, religion, anything like that, even if, in fact, something could interfere with their job (eg, a single parent of 3 interviewing for a job that's 80% travel). Asking, even just conversationally before or after the interview, can make it seem as if that is something which is a factor in hiring them. If they offer information, fine, but never ask.
The funny thing about those books was that our heros were capable of faster than light travel, but they had to do all their interstellar navigation using slide rules!
Some Heinlein short stories are like that, though not quite so bad. In one story a rocket to the moon (or Mars, I foget) has to radio to a space station in orbit around Earth to get calculations done (on mechanical calculators!).
Just out of interest, how is the second word pronounced ?...
Roughly: Hoy-ginz. We got a pair of servers in a few months ago, named them Cassini and Huygens. First thing we had to do was look that up exactly that.:)
Slashdot Mirror
Probably? I'll grant you that the output of SHA-512 is going to be longer than combining several small hashes, but I don't intuitively see that it's necessarily more secure.
See Joux's work on multicollision attacks. While it was thought (before he developed this attack) that taking a (secure) N-bit hash and a (secure) M-bit hash and concatenating the outputs was equivalent to a secure (N+M)-bit hash, it turns out this is not the case - it's more like a max(N,M)-bit hash, for (some) security purposes, such as collision resistance.
It's not intuitive, though - at least not until after you see the attack. We had been designing and using hashes based on the Miyaguchi-Preneel and Davies-Meyer methods for well over a decade before Joux noticed the problem.
The thing that really makes me want to stay away from Microsoft software (and proprietary software in general, though Microsoft seems particularly prone to it) is exactly this sort of behavior. For a long time I've had the sentiment that Unix was more secureable than Windows (securable, not secure-out-of-the-box, since neither of them is that), precisely because I find it much easier to look at a Unix system (particularly one which I have the full sources to) and understand what it is doing than I do when using a Windows system.
I assume this is actually undocumented behaviour, since I haven't seen anyone claim to have known about it before now, nor can I find any references on MSDN about it. Having unintuitive and undocumented behaviour is exactly the sort of thing that makes it very hard to gain a correct mental model of how a system behaves, and if you don't even understand how the system works I don't see how one can secure or troubleshoot the system in a way that isn't essentially "shotgun debugging".
My $.02
New users are led to believe they can take hardware compatability for granted as they did with Windows
In my experience, assuming anything is compatible with Windows is also a bad assumption. Sure, you'll almost certainly be able to get a driver, but there is a reasonable chance that it's a complete POS that will make your system stupidly unstable, will never be updated once the hardware is no longer sold (or once the vendor is bought or goes out of business or changes product focus or whatever), and at some point you'll do a patch install and it will suddenly stop working. Overall I find driver _quality_ to be much better on Linux than on Windows -- with the notable and serious exceptions of video card drivers (and of wireless cards up until a couple of years ago).
Of course most of the larger/better manufactuers have quality Windows drivers, but then again that is exactly the space where the Linux drivers are also pretty strong (never had driver problem on either platform with, say, an Intel E100 NIC, or an SB Live).
Funny how you never really hear about the applications written in COBOL, Fortran and PL/1 crashing.
Not really. They were probably written 20 or more years ago, there has been plenty of time to catch most of the bugs. Not a function of language, techniques, or skill, just time and use. And stuff written in COBOL and PL/1 probably doesn't get touched much, so no new bugs.
I'd love to see some uptime numbers for past systems versus the systems we have today. I wonder if they'd show the downward trend that I suspect they would.
On average, sure. Most servers don't stay up for more than a few months, a couple of years at best. But they also cost a lot less than an S/360 did in 1965. You want a box that will stay up, buy a Tandem or something.
As anyone who's tried out x86 Solaris is aware; it's no match for Linux on the platform - or any other platform other than Sun's own hardware for that matter.
Even on Sun hardware, Linux or *BSD can be a win. Sure, on an E10K Solaris will be faster than Linux, but on an SparcStation or early Ultra, Solaris is not that snappy. I would like to have a Sun box fast enough to run Solaris on, to keep current on Solaris administration, but on my current Sun machines it's not worth it.
There also is/was:
KAI C++ is basically dead (Intel bought them a couple years back, which sucks, as KAI was about the best C++ compiler I have seen), and I'm not totally sure about Compaq's Alpha compiler, but it looks like the SGI Pro64 compiler is still alive (and GPL'ed now... interesting).
Isn't this in line with the whole "No machine[usually meaning computer, but in this case a jumpdrive] is secure if the physical box is in the hands of the hacker/criminal."
Yes and no. There are devices which are designed to remain secure even in the hands of a high-level attacker with major resources, and destroy their keys if they detect they are being tampered with. Mostly used by banks and the military, as it's very expensive to build all the countermeasures in. One nice one is the IBM 4758, which IIRC runs for about 10K a pop. The IBM 4758 actually has a protocol error that lets you attack it without breaking through the physical protections, but no reason a system with a 'fixed' protocol set couldn't be built.
But due to size and cost, no way you can build countermeasures like that onto a jumpdrive.
- Voice controlled robots ("You missed a corner, vacuum cleaner")
- Data search by voice ("Find me a channel that plays Star Trek")
Kinda jumping ahead of yourself, aren't you? There are two steps to an operation like these, speech to text, and understanding the text you get out. Speech recognition gives you the first part, but you still have to be able to pull apart the sentence and figure out what it means.
Also, the article didn't say more accurate than software, it said more efficient. You know, uses less power and stuff like that? If the applications you mention (like search via voice) were possible/usable, you could run them today on an upper-end PC no problem.
I guess I just don't understand why the MPAA's members would rather sit around and piss and moan about piracy instead of trying to defeat it. It's not like it's impossible to make a good deal of extra money off of it.
Control. They would rather have 99% of a market worth $10 billion than 50% of a market worth $100 billion.
Just what I wanted. (Disclaimer: I haven't seen these particular movies, so perhaps they are better than I'm guessing based on ROTJ.)
I remember liking them when I saw them on tape when I was around 8 or so. Of course, I was 8. I remember being sort of freaked out by the giant spiders (they dined on Ewoks), but I suspect if I saw any of them again I wouldn't be terribly impressed.
haven't you seen ocean's 11?
No.
if they seriously hit the city with a massive EMP burst it would have been downtime for alot longer than a few seconds...
Yeah, that's kind of the point, isn't it?
I wasn't there this year. A friend told me that the embarrassing thing was that the Chinese paper was REJECTED from the conference. They presented their results at the rump session.
Of course, it would have helped the paper's chances of being accepted if:
a) They had actually presented the methods they used
and/or
b) The results had been correct. Initially, they were not finding collisions for MD5, but what they *thought* was MD5 (due to a translation error).
So what the reviewers read was a claimed attack on MD5, with no details, and their examples did not work. If I were reviewing that paper, I would have rejected it too. They didn't correct the paper until (IIRC) the day before the rump session.
If, after a nuclear war, you spend your time hunting for Planck's Constant (or server documentation) instead of food
There are non-nuclear EMP devices, you know. Also, to quote from the link the grandparent provided:
"A large device detonated at 400-500 km over Kansas would affect all of CONUS. The signal from such an event extends to the visual horizon as seen from the burst point."
Usual airburst detoniation for an ICBM (at least from what I found on Google) is in the 4-20 km range. That is to say, once could take out a lot of computers while causing relatively little physical damage.
Now the neighbor's kid can activate my credit cards he stole from my mailbox without breaking into my place to use my phone line.
A lot of the CC companies don't bother checking anyway. Last time I activated a card, I did it from a friend's landline, as I spent a few (rather nice) years without a phone of any sort, and I had no trouble at all activating it.
and a K&R C compiler - and not a "modernized" just-pre-ANSI one either, I mean something that choked on function prototypes in a way my Sinclair QL's Metacomco C compiler didn't back in 1995...
In case anyone's interested, this is a HP-UX 11 (the machine is a 9000/800) system
That C compiler is (AFAIK) only shipped for building new versions of the kernel. You can also buy a reasonably decent C99/C++98 compiler from HP for about a zillion dollars. The reason they cripple the shipped compiler is to force you to buy the real compiler (or install GCC, of course). So HP isn't really a K&R only system (I mean c'mon, how could you sell a system like that anytime in the last 10 years?), it just ships with a crippled compiler, which is a shame because some people continue to insist that it's usable for anything -- it's not.
Basically a EAL or Orange book certified system will not allow casual transfer of data from a higher security level to a lower security level. That is the core of the qualification concept. All the stuff about admin roles, etc is just fluff oriented towards managing the concept and the granularity to which it is managed.
/tangent
Ummmmmm... no. Multilevel security was only a requirement in the Orange Book of level B1 or higher. C1/C2 evaluated systems did not need any sort of MLS. There are Unix-based MLS systems (Trusted IRIX was evaulated at either B1 or B2, IIRC), but they are not common, and generally pretty painful (an attribute shared with all other MLS systems). In normal Windows or Unix systems, there is no labeling of data, there are nwhich would be kind of a waste of money, but hey.o controls preventing you from sharing information with other users, none of that. And for good reason - MLS is about information control, while people generally get work done by *sharing* information. The only people who want MLS are the military/intel groups, and from what I've heard, most of the people using it there don't like it much either.
As for CC, there is absolutely no requirements whatsoever in terms of protection. With the right proection profile, you could probably get MS-DOS to EAL2 at least. In this case the profile would say "this OS doesn't do anything security-wise", and then the evaulation would prove that this protection profile was correct.
Also, it's Aleph1, not Alef1. Hebrew letter (or, in this case, a Hebrew letter + number, specifying a transfinite number).
(1) If we're so stupid we can destroy the only planet we live on, I don't see how we're doing the universe a favor by spreading.
If we had self-sustained colonies on other planets, wouldn't this mean we weren't blowing up the only planet we live on when we finally get around to blowing up the Earth? Because, you know, we would have those other ones.
I think that having experts able to review each line of code checked in and put into production defeats the whole idea of using Open Source: at that point, you might as well just hire the experts to write the code in the first place and eliminate the vector all together.
The whole point of evaluation/audit is that the people who check the code are not the people who wrote it. That's why if you want a CC or FIPS 140 evaluation, you fork over half a mil or more to a testing lab.
My understanding was that this is not true. At best you get the square root of the number of steps that would be required for a non-quantum brute force search. This means that key sizes are effectively halved, but that isn't an insurmountable problem.
Bingo. Which is why the AES competition required support for 256 bit keys, when even 128 bits is out of reach by any conceivable technology.
Factoring is one such case, which is why quantum computing spells the death of RSA.
Not true, necessarily. Shor's algorithm is algorithmically faster than the generalized number field sieve, but there is a constant in there. We don't know how big that constant is, and we won't until we have a quantum computer big enough to run Shor's algorithm (30 qubits or so, IIRC). It's entirely possible that Shor's algorithm is only faster then the GNFS once you hit keysizes of 10,000 bits, in which case it doesn't matter. OTOH, if Shor's algorithm is faster than the GNFS on 256 bit keys, we are, indeed, in some trouble. Of course running Shor's algorithm on a 1024 bit RSA key would take quite a large quantum computer, too.
And, as you mention, there is no algorithm for compute discrete logarithms much faster than usual on quantum computers. I haven't heard about such an algorithm, anyway. Doesn't mean it doesn't exist, of course.
Summary: algorithmic complexity is not the sole determinant of algorithm running time.
In summary, quantum computing is powerful, but not a magic wand that makes all classical encryption schemes invalid.
Thank you. Every time a quantum crypto or quantum computing store pops up here, the hype level seems to increase by several orders of magnitude. It's really annoying.
From article: And thanks to a 10-year technology pact, Sun's servers will be certified to run Windows.
Ummmm... what the fuck? I've got to assume this is just plain wrong, since it seems to imply either that MS will be porting Windows to SPARC, or that Sun is dropping SPARC, or something like that. Maybe they just mean the Opteron and x86 based systems? If so, not exactly a huge deal, especially considering that Sun's x86 stuff is just the same as stuff you can get from HP or Dell, just with a Sun logo.
However, at one point, sooner or later, you need to pickup the cheque or cash. Wire transfers can be traced, as can direct deposits. If there's a cash-only transaction, the cash can be marked and the police can watch the drop point.
At least until we finally get a practical electronic cash system set up. Untraceable and unforgeable. "You will post $10,000 worth of electronic cash certificates to alt.test.messages, encrypted with this (throwaway) PGP key on this date".
Of course given that we've known how to build one for over 15 years and still nobody is using one, it seems the economic and social problems far outweight the technical ones on this issue. IIRC some of the core patents expire pretty soon, maybe that will spur something on, but I kinda doubt it.
not sure you are allowed to ask that in an interview.
You're not. Or rather, you can, but it opens you/your company up for a lawsuit. Standing rules at my work for interviewing: no questions about wife, children, religion, anything like that, even if, in fact, something could interfere with their job (eg, a single parent of 3 interviewing for a job that's 80% travel). Asking, even just conversationally before or after the interview, can make it seem as if that is something which is a factor in hiring them. If they offer information, fine, but never ask.
The funny thing about those books was that our heros were capable of faster than light travel, but they had to do all their interstellar navigation using slide rules!
Some Heinlein short stories are like that, though not quite so bad. In one story a rocket to the moon (or Mars, I foget) has to radio to a space station in orbit around Earth to get calculations done (on mechanical calculators!).
"Cassini-Huygens"
:)
Just out of interest, how is the second word pronounced ?...
Roughly: Hoy-ginz. We got a pair of servers in a few months ago, named them Cassini and Huygens. First thing we had to do was look that up exactly that.
Really. I didn't make that up, check the link! Who is this guy, and why is he giving me software security advice?!
Member of the IAB. Co-chair of the TLS working group.