two-person login?
Hi Folks -- I have been asked to opine on a system that requires a two-person login. Some AIX documents refer to this as a common method of increasing login security http://www.redbooks.ibm.com/redbooks/pdfs/sg245962.pdf However, I don't think it is very common; I get only five hits from http://www.google.com/search?q=two-person-login By way of not-very-apt analogy: -- I am aware of business checks that require two signatures; -- I am aware that purchase orders are commonly signed by two persons (the initiator and the approver); -- I am aware of missile-launch procedures that require two persons using two keys; -- I am aware of software development procedures where a patch is submitted (and signed) by one person, tested (and signed off) by another, and committed to the official repository by a third person. -- et cetera. However, it is important to note that the aforementioned examples all share an important property, as we see from the following: *) The parties give their approval _after_ the semantics has been fully determined. It would defeat all security if two signatures were attached to a blank check or a blank PO. *) As a related point, the approval is attached to a particular transaction. The approver is not merely certifying that Joe is really Joe, and is generally allowed to write checks (mere identification); the approver is certifying that this particular check is OK. *) To say the same thing another way, there is no pretexting. There is no pretext for turning the keys on the missile launcher unless you intend to launch a missile. The semantics of the keys is clear. We need to talk about threat models: a) The purveyors of the system in question don't have any clue as to what their threat model is. I conjecture that they might be motivated by the non-apt analogies itemized above. b) In the system in question, there are myriad reasons why Joe would need to log in. If Joe wanted to do something nefarious, it would take him less than a second to come up with a seemingly non-nefarious pretext. When the approver approves Joe's login, the approver has no idea what the consequences of that approval will be. The two-person login requires the approver to be present at login time, but does not require the approver to remain present, let alone take responsibility what Joe does after login. c) The only threat model I can come up with is the case where Joe's password has been compromised, and nobody else's has. Two-person login would provide an extra layer of security in this case. This threat is real, but there are other ways of dealing with this threat (e.g. two-factor authentication) ... so this seems like quite a lame justification for the two-person login. d) Or have I overlooked something? From the foregoing, you might conclude that the two-person login system is worthless security theater ... but harmless security theater, and therefore not worth worrying about either way. But the plot thickens. The purveyors have implemented two-person login in a way that manifestly /reduces/ security. Details available on request. So now I throw it open for discussion. Is there any significant value in two-person login? That is, can you identify any threat that is alleviated by two-person login, that is not more wisely alleviated in some other way? If so, is there any advice you can give on how to do this right? Any DOs and DONTs? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Earliest indication of Prime numbers
From a fun article on the history of computing http://www.neatorama.com/2008/01/25/the-wonderful-world-of-early-computing The 20,000-year-old bone revealed that early civilization had mastered arithmetic series and even the concept of prime numbers. This predates the Egyptian and Greek references to prime number knowledge I have heard about by a wide margin. Unfortunately, the article doesn't go into any more detail then the quote above. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
On Jan 25, 2008, at 4:27 PM, Perry E. Metzger wrote: However, you should be very skeptical when someone claims that they need to use a home grown crypto algorithm or that they need to use a home grown protocol instead of a well proven one. I'm beginning to suspect that more often than not, this nonsense is a result of market forces rather than idiot technologists. In my experience, senior decision-maker types outside of the computer industry (and even within it, but perhaps a tad less so) are sufficiently non-technical as to never have heard of Kerckhoffs' principle -- and to disbelieve it when they do, since it opposes their intuition of what makes for secure systems. Various companies (or departments) then emerge peddling their home-grown crypto and trumpeting the fact that it's proprietary as a feature, commonly going hand in hand with stupidly large key sizes. Some number of these muppets approached me over the last couple of years offering to donate a free license for their excellent products. I used to be more polite about it, but nowadays I ask that they Google the famous Gutmann Sound Wave Therapy[0] and mail me afterwards. I've never heard back. [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238 -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Mon, Jan 28, 2008 at 03:56:11PM -0700, John Denker wrote:
[...]
I don't think it is very common; I get only five hits from
http://www.google.com/search?q=two-person-login
[...]
Try searching for secret splitting instead.
From the foregoing, you might conclude that the two-person login
system is worthless security theater ... but harmless security
theater, and therefore not worth worrying about either way.
[...]
So now I throw it open for discussion. Is there any significant
value in two-person login? That is, can you identify any threat
that is alleviated by two-person login, that is not more wisely
alleviated in some other way?
[...]
I don't think it's security theater at all, as long as established
procedure backs up this implementation in a sane way. For example,
in my professional life, we use this technique for commiting changes
to high-priority systems. Procedure is that two security admins
(each with half of a cryptographic key) collaborate on updates. Sure
there's still the risk that one is nefarious and will socially
engineer a back door in while his/her counterpart is watching, but
that is not so much the risk we are attempting to thwart. The real
goal is to reinforce policy which requires collaboration between
administrators for major changes to these important systems.
Technology can't effectively *force* procedure (ingenious people
will always find a way around the better mousetrap), but it can help
remind them how they are expected to interact with systems.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Gutmann Soundwave Therapy
Clearly, more people need to know about Gutmann Soundwave Therapy. Ivan Krstić [EMAIL PROTECTED] writes: [...] but nowadays I ask that they Google the famous Gutmann Sound Wave Therapy[0] and mail me afterwards. I've never heard back. [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238 As it turns out, the central image of Peter's post was popularized earlier*. However, Peter clearly said this first in a security context, and I hope that the term Gutmann Soundwave Therapy spreads widely within our field as a way of ridiculing the desire to invent your own crypto algorithms and protocols. When it gets to the point where salesmen are vaguely aware of the phrase and fear it, we will know we have done our job successfully. Perry [* see http://jwz.livejournal.com/123070.html#t521918 for its use in a different context. (Hat tip to Ekr and indirectly to Need to Know: http://www.ntk.net/2004/01/09/ )] -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
another term you might look for (used in physical security and financial controls) is dual custody or sometimes double custody. (if you're searching, add -child or security for better search quality) i don't see why the analogies are not apt. one question is whether the two people can both perform their respective act independently or whether they need to perform their act within a bounded time. in the case of auditcon locks, for example, often used on the money safe part of atms: http://www.kaba.co.uk/products/auditcon-2-series-model-252.asp these features are called Supervisor/Subordinate Mode Allows access by a subordinate only after being enabled by a supervisory combination. Once enabled, a subordinate user has access to the lock during any valid opening time. [for example, this would be used in a supermarket if a manager wants to allow a subordinate to open the safe the next morning] or Dual Custody Two Person Integrity, which requires two users to open the lock. the x-09 (approved for use in us top secret) has three modes: A-single combination code b-Dual combination mode which allows access only when two different three number combinations are dialed within 10 seconds of one another c-Supervisory/subordinate mode On Jan 28, 2008, at 2:56 PM, John Denker wrote: Hi Folks -- I have been asked to opine on a system that requires a two-person login. Some AIX documents refer to this as a common method of increasing login security http://www.redbooks.ibm.com/redbooks/pdfs/sg245962.pdf However, I don't think it is very common; I get only five hits from http://www.google.com/search?q=two-person-login By way of not-very-apt analogy: -- I am aware of business checks that require two signatures; -- I am aware that purchase orders are commonly signed by two persons (the initiator and the approver); -- I am aware of missile-launch procedures that require two persons using two keys; -- I am aware of software development procedures where a patch is submitted (and signed) by one person, tested (and signed off) by another, and committed to the official repository by a third person. -- et cetera. However, it is important to note that the aforementioned examples all share an important property, as we see from the following: *) The parties give their approval _after_ the semantics has been fully determined. It would defeat all security if two signatures were attached to a blank check or a blank PO. *) As a related point, the approval is attached to a particular transaction. The approver is not merely certifying that Joe is really Joe, and is generally allowed to write checks (mere identification); the approver is certifying that this particular check is OK. *) To say the same thing another way, there is no pretexting. There is no pretext for turning the keys on the missile launcher unless you intend to launch a missile. The semantics of the keys is clear. We need to talk about threat models: a) The purveyors of the system in question don't have any clue as to what their threat model is. I conjecture that they might be motivated by the non-apt analogies itemized above. b) In the system in question, there are myriad reasons why Joe would need to log in. If Joe wanted to do something nefarious, it would take him less than a second to come up with a seemingly non-nefarious pretext. When the approver approves Joe's login, the approver has no idea what the consequences of that approval will be. The two-person login requires the approver to be present at login time, but does not require the approver to remain present, let alone take responsibility what Joe does after login. c) The only threat model I can come up with is the case where Joe's password has been compromised, and nobody else's has. Two-person login would provide an extra layer of security in this case. This threat is real, but there are other ways of dealing with this threat (e.g. two-factor authentication) ... so this seems like quite a lame justification for the two-person login. d) Or have I overlooked something? From the foregoing, you might conclude that the two-person login system is worthless security theater ... but harmless security theater, and therefore not worth worrying about either way. But the plot thickens. The purveyors have implemented two-person login in a way that manifestly /reduces/ security. Details available on request. So now I throw it open for discussion. Is there any significant value in two-person login? That is, can you identify any threat that is alleviated by two-person login, that is not more wisely alleviated in some other way? If so, is there any advice you can give on how to do this right? Any DOs and DONTs? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Dutch Transport Card Broken
Why require contactless in the first place? Is swiping one's card, credit-card style too difficult for the average user? I'm thinking two parallel copper traces on the card could be used to power it for the duration of the swipe, with power provided by the reader. Why, in a billion-dollar project, one must use COTS RFIDs - with their attendant privacy and security problems - is beyond me. A little ingenuity would have gone a long way. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karsten Nohl Sent: Monday, January 28, 2008 12:41 AM To: Aram Perez Cc: Cryptography Subject: Re: Dutch Transport Card Broken Not to defend the designers in any way or fashion, but I'd like to ask, How much security can you put into a plastic card, the size of a credit card, that has to perform its function in a secure manner, all in under 2 seconds (in under 1 second in parts of Asia)? And it has to do this while receiving its power via the electromagnetic field being generated by the reader. You are raising a very interesting point. The constraints under which RFIDs and contactless smart-cards need to operate seem to vary widely depending on the application. The Mifare Classic cards, for example, authenticate in under 2 ms, but wouldn't need to be that fast as you point out. Their crypto is also very small, much smaller even than their flash memory. What good is it, though, to have a lot of memory that is badly protected? Last, the power consumption of the Mifare cards is certainly lower than others, which doesn't matter, though, in the near-field where even micro-processor based designs can operate. This is where contactless smart-cards and RFIDs get confused often. Only for the latter ones power consumption is a limiting constraint. To answer your question directly: Within the limits of Mifare Classic (48-bit cipher, 16-bit RNG), one can build a 64-bit cipher that generates 'random' numbers internally. Within the same limits, one could almost implement TEA which at least has undergone its share of peer-review. Again: Trading some of the memory for this much higher level of security would certainly have been worth it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
John Denker wrote: We need to talk about threat models: a) The purveyors of the system in question don't have any clue as to what their threat model is. I conjecture that they might be motivated by the non-apt analogies itemized above. b) In the system in question, there are myriad reasons why Joe would need to log in. If Joe wanted to do something nefarious, it would take him less than a second to come up with a seemingly non-nefarious pretext. When the approver approves Joe's login, the approver has no idea what the consequences of that approval will be. The two-person login requires the approver to be present at login time, but does not require the approver to remain present, let alone take responsibility what Joe does after login. c) The only threat model I can come up with is the case where Joe's password has been compromised, and nobody else's has. Two-person login would provide an extra layer of security in this case. This threat is real, but there are other ways of dealing with this threat (e.g. two-factor authentication) ... so this seems like quite a lame justification for the two-person login. d) Or have I overlooked something? OK, putting on the devil's advocate hat cape here... Consider the latest case with SocGen where a trader goes rogue (so the news has it at least). One might argue that the system you are talking about provides a control over that. From the foregoing, you might conclude that the two-person login system is worthless security theater ... but harmless security theater, and therefore not worth worrying about either way. There is the possibility of compliance controls. In audits and sarbanes-oxley and other things there is frequent talk of dual control and 4 eyes principle. Now, it could be that these points can be easily covered by employing a system that enforces this. Often, auditors will be convinced if they can see something in place, and not feel the need to audit the system itself. The auditor's job is done when he can safely say management has put in place procedures... and the system you mention meets that protocol in words at least. But the plot thickens. The purveyors have implemented two-person login in a way that manifestly /reduces/ security. Details available on request. So now I throw it open for discussion. Is there any significant value in two-person login? That is, can you identify any threat that is alleviated by two-person login, that is not more wisely alleviated in some other way? It might be useful for management to decree that all juniors must work with a senior watching over. Also e.g., critical systems where two systems administrators work together. In linux there is a program called screen(1) that allows two sysadms to share the same screen and type together. This has a lot of value when two minds are better than one. But, yes, this is not quite what you are describing. Also, it might be a control to enforce other procedures. If the sysadm is given the controls to some departmental system, then instead of just waltzing in and playing with it, he has to ask the non-techie boss, who then asks what the story is. This way she can know that the appropriate procedures are in place, such as notification to users. It's far easier to figure out what the sysadm is up to if he is forced to have a conversation every time he wants to log in... this addresses your point b above, in that it now clearly labels any disaster as something the sysadm should have told the boss about before, instead of leaving it in the murky area of of course I intended to scrub the disks, that's my job! If so, is there any advice you can give on how to do this right? Any DOs and DONTs? I'd expect a proper physical token to be the manager's login mechanism. If it was a password he typed in there would be too much incentive to share the password. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Tue, Jan 29, 2008 at 06:34:29PM +, The Fungi wrote: On Mon, Jan 28, 2008 at 03:56:11PM -0700, John Denker wrote: So now I throw it open for discussion. Is there any significant value in two-person login? That is, can you identify any threat that is alleviated by two-person login, that is not more wisely alleviated in some other way? [...] I don't think it's security theater at all, as long as established procedure backs up this implementation in a sane way. For example, in my professional life, we use this technique for commiting changes ... I think you missed John's point, which is that two-person *login* says *nothing* about what happens once logged in -- logging in enables arbitrary subsequent transactions that may not require two people to acquiesce. What if one of the persons leaves the other alone to do whatever they wish with the system? Or are the two persons chained to each other? (And even then, there's no guarantee that they are both conscious at the same time, that no third person shows up and knocks them out *after* they've logged in, ...) Technology can't effectively *force* procedure (ingenious people will always find a way around the better mousetrap), but it can help remind them how they are expected to interact with systems. When you force two people to participate on a *per-transaction* basis then you probably get both of them to pay attention, though such schemes might not scale to thousands, or even hundreds of transactions per-team, per-day. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On 01/29/2008 11:34 AM, The Fungi wrote: I don't think it's security theater at all, as long as established procedure backs up this implementation in a sane way. For example, in my professional life, we use this technique for commiting changes to high-priority systems. Procedure is that two security admins (each with half of a cryptographic key) collaborate on updates. Sure there's still the risk that one is nefarious and will socially engineer a back door in while his/her counterpart is watching, but that is not so much the risk we are attempting to thwart. The real goal is to reinforce policy which requires collaboration between administrators for major changes to these important systems. Technology can't effectively *force* procedure (ingenious people will always find a way around the better mousetrap), but it can help remind them how they are expected to interact with systems. OK, that's clear and helpful. Thanks. The point I take away from this is that _procedure_ is primary and fundamental. Technology is secondary. The two-person login is technology, and it is only icing on the procedural cake. -- If you have a good procedure, the two-person login might help remind people to follow the procedure. -- If you don't have a good procedure, having a two-person login will not magically create a good procedure. This also gets back to what I said previously about semantics. In the situation The Fungi described, the semantics is clear. A login is tantamount to a commit, and the semantics of commit is clear. Both parties make sure they understand the commit before they log in. Both parties log in, both parties hang around until the commit is complete, then both parties log out and leave. One question: If the goal is to have a two-person commit, why not implement a two-person commit, rather than using two-person login as a proxy? For years there have been paperless office workflow systems that require two digital signatures on a purchase order. If you're going to use technology to support procedure, IMHO the technology should be tied as tightly as possible to the procedure. The semantics of login is IMHO very unclear, very open-ended, and it takes a lot of hand-waving to tie the login technology to the commit semantics. The foregoing makes sense, and is in extreme contrast to the situation I am faced with, where Joe logs in with the help of Jane, and then Jane leaves. Jane has not the slightest control over what Joe does while logged in. I don't see a sane procedure here. It seems Jane is signing a blank check. It wouldn't be so bad if there were a development system separate from the production system, but there isn't, so Joe spends all day every day logged into the high security production system. Joe can commit anything he wishes. There is no two-party review of the commit, just two-party review of the login. Just to rub salt in the wound, they've got it set up so that everybody uses the Admin account. There are N people who know the first half of the Admin password, and M people who know the second half. Besides being an incredibly lame form of secret-splitting, this has the nasty property that when Admin logs in, you don't even know who was involved. There are M*N/2 possibilities. There is no accountability anywhere. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Crawford Nathan-HMGT87 wrote: Why require contactless in the first place? Is swiping one's card, credit-card style too difficult for the average user? As compared to slapping your wallet on the reader? yes. I swipe my Visa / debit / Tim Horton's cards regularly. With the plethora of bad reader technology out there, no matter how practiced I am it sometimes takes 2-3 tries to get a good read. Heck, sales clerks who swipe hundreds of times per day sometimes have trouble. And that's with a relatively easy to read magnetic stripe... GO Transit here in Toronto ran a pilot program with contactless stored-value fare cards several years ago, which worked quite well; I'm sure technology details are available via Google. Alas, the project got squashed by a political movement for a Greater Toronto Area fare card project (which still hasn't gone anywhere 5-6 years later...). -- Harald - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Harald Koch [EMAIL PROTECTED] writes: Crawford Nathan-HMGT87 wrote: Why require contactless in the first place? Is swiping one's card, credit-card style too difficult for the average user? As compared to slapping your wallet on the reader? yes. I swipe my Visa / debit / Tim Horton's cards regularly. With the plethora of bad reader technology out there, no matter how practiced I am it sometimes takes 2-3 tries to get a good read. Heck, sales clerks who swipe hundreds of times per day sometimes have trouble. And that's with a relatively easy to read magnetic stripe... Here in New York City, we use a swipe based system called Metrocard. New Yorkers are not known for passive, accepting behavior, and yet no one seems to complain about the swipe system -- it seems to work more than well enough, and I have to double swipe at most once every few dozen times. The system has held up quite well to quite determined attacks, and the cards themselves are insanely cheap to produce. I therefore expect no one else will ever use the technology -- anything cheap, secure and well tested in the field can't possibly see wide adoption. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
On Tue, Jan 29, 2008 at 03:37:26PM -0600, Nicolas Williams wrote:
I think you missed John's point, which is that two-person *login*
says *nothing* about what happens once logged in -- logging in
enables arbitrary subsequent transactions that may not require two
people to acquiesce.
Certainly, but then neither does a one-person login (people can
always log into a system and then walk away to get a cup of coffee,
for that matter).
What if one of the persons leaves the other alone to do whatever they
wish with the system? Or are the two persons chained to each other?
(And even then, there's no guarantee that they are both conscious at the
same time, that no third person shows up and knocks them out *after*
they've logged in, ...)
Of course, this is common sense. These are human problems which I do
not think can *ever* be solved through application of cryptography.
As I said, requiring two sets of credentials can act as a reminder
to work together, nothing more. There's no way that I know of to
force a person to pay attention, or for that matter do anything they
do not wish to do.
When you force two people to participate on a *per-transaction* basis
then you probably get both of them to pay attention, though such schemes
might not scale to thousands, or even hundreds of transactions per-team,
per-day.
Agreed--it would be nonsense to dream otherwise. My only point was
to suggest that there are some circumstances in which a system like
this can be helpful/useful, which was one of the questions John
asked. It is simply necessary that when employing such a system, you
be aware of what problems it actually *can* solve, and what problems
it cannot. I have no doubt that some people attempt to employ these
sorts of solutions in ways which they are indeed inapplicable (or
put too much faith in the false sense of security it gives them),
possibly at the urging of their snake oil vendors. This is why
scrutiny of the *application* of a technology is at least as
important as scrutiny of the technology itself.
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP([EMAIL PROTECTED]); IRC([EMAIL PROTECTED]); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER([EMAIL PROTECTED]);
MUD([EMAIL PROTECTED]:6669); WWW(http://fungi.yuggoth.org/); }
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
US reforming export controls
The Bush administration is reforming the way export controls are administered; see http://www.fas.org/blog/ssp/2008/01/bush_administration_unveils_ne.php It's too soon to know if crypto will be affected; certainly, it's something to watch. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: two-person login?
Hi, I have been asked to opine on a system that requires a two-person login. Some AIX documents refer to this as a common method of increasing login security http://www.redbooks.ibm.com/redbooks/pdfs/sg245962.pdf I would like to have a two-person remote login: The server is in the datacenter, two sysadmins login remotely (SSH or something similar), and the login only works if both are there. As soon as either one drops the connection, the other one is frozen too. They should see what each other is doing (key-press logging of the other admin in the bottom line) (In case they detect the other sysadmin doing something evil, they can simply disconnect, which also disconnects/freezes the other one) I would be happy about such an implementation in a SSH server. (combined with screen perhaps ...) Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Dutch Transport Card Broken
Ivan Krstic' wrote: Some number of these muppets approached me over the last couple of years offering to donate a free license for their excellent products. I used to be more polite about it, but nowadays I ask that they Google the famous Gutmann Sound Wave Therapy[0] and mail me afterwards. Gutmann Sound Wave Therapy: Gutmann recommends: : : Whenever someone thinks that they can replace : : SSL/SSH with something much better that they : : designed this morning over coffee, their : : computer speakers should generate some sort : : of penis-shaped sound wave and plunge it : : repeatedly into their skulls until they : : achieve enlightenment. On SSL, Gutmann is half wrong: SSL key distribution and management is horribly broken, with the result that everyone winds up using plaintext when they should not. SSL is layered on top of TCP, and then one layers one's actual protocol on top of SSL, with the result that a transaction involves a painfully large number of round trips. We really do need to reinvent and replace SSL/TCP, though doing it right is a hard problem that takes more than morning coffee. As discussed earlier on this list, layering induces excessive round trips. Layering communications protocols is analogous to having a high level interpreter written in a low level language. What we need instead of layering is a protocol compiler, analogous to the Microsoft IDL compiler. The Microsoft IDL compiler automatically generates a C++ interface that correctly handles run time version negotiation, which hand generated interfaces always screw up, with the result that hand generated interfaces result in forward and backward incompatibility, resulting in the infamous Microsoft DLL hell. Similarly we want a compiler that automatically generates secure message exchange and reliable transactions from unreliable packets. (And of course, run time version negotiation) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Beating Colossus: an interview with Joachim Schueth
http://www.netbsd.org/gallery/schueth-interview.html Beating Colossus: an interview with Joachim Schueth Joachim Schueth has beaten a reconstruction of the famous Colossus Mark II code breaking machine in November 2007. The Colossus computers were used in World War II to break the German encrypted messages. Equipped with a NetBSD-powered laptop and profound knowledge of cryptography and the Ada programming language, Schueth has won the code-cracking challenge. We talked with him about the historical and technical backgrounds of the Cipher Event and the tools he has used. -- Sean McGrath [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
