I'm moving all of our development machines (running FC) and servers (running RedHat) to Centos. I got fed up with the terrible bandwidth available to RedHat up2date users (for $350 per machine per year I expect to get the bandwidth I need to update infrequently) and the lack of cheap centralised mangement.
With Centos (and other apt/yum based clones) I can set up a local repository and save the network the trouble.
Also it would definitely simplify your weight distribution. I prefer integrated weights (being overweight I am very bouyant and so need a lot) and , in conjunction with a tank, they can definitely cause a lot of BCD inertia.
Of course, I'm wondering how well all those neat holds you learn in PADI Rescue will work without a big tank stem/First Stage to grab.
Try setting up a proper security architecture for it using SASL and/or TLS to support samba and pam SSO.
I know LDAP very well and have worked with many different servers but trying to find the exactly correct version of openldap to support properly secured passwords for samba manager and root in the DIB was a nightmare. I eventually gave up and had to go back to the security requirements phase to get around it.
As for hoping to train up the less experienced admins on the system, I was pretty sure that would never be possible.
The whole point of a patent is that it is anti-competitive. It is there to protect you from competition so that you are encouraged to publicise the work.
As is widely known, trademarks usually only apply to a single category and a in the countries they are registered in.
Coca-Cola are in the fortunate position of having some of the very, very few trademarks which apply across the categories. Coca-Cola and Coke are both trademarks and both are recognised in this manner.
In addition, as noted in the discussions, a Swiss person might reasonably expect coke.ch to refer to a Coca-Cola site whereas cocaine.ch would meet the requirements for a cocaine site perfectly. It is surprising that Sitzerland has no.org.ch separation given the size of its population and the central role it has played in the net.
I work for a crypto company too and I concur with the above statement. While there are asymmetric stream algorithms (RPK is the main one, I believe) most of the existing knowledge is of using asymmetric algorithms to share session keys for stream ciphers. It is always good idea to go with the most used algorithms unless there are known deficiencies in them. See any of Bruce Schneier's Cryptogram newsletters for reasons (http://www.counterpane.com).
Two points:
1) It is better to use a real stream cipher (such as RC4/Arcfour or one of the LFSR based ones) since they all emit a single byte at a time and are very fast. Key entropy is not necessarily a problem with the LFSR based ones since you will be generating the session keys automatically (must be from a good PRNG). CBS-mode block algorithms are fine too but the performance will usually leave something to be desired.
2) ALWAYS generate a new session key for each encryption session and preserve state for the duration of the session. NEVER start a new stream with the same key or reset the state to the initial value in mid-stream (e.g. for resynchronisation). If you get this wrong you might as well send it all in clear (since the XOR attacks are basically trivial).
I find that most things I want to do with CGI benefit greatly from Perl's fast, simple text handling. The need to roll your own versions of the standard Perl text mangling functions really puts me off.
That said, I did reimplement a pretty big Perl CGI in C a while back, in part for speed but mainly because it had to go in with a C based backend suite and the developers didn't know Perl and so couldn't support the old CGI.
I agree with these comments. I've been using online EB for just over a year now (they extended my membership to eighteen months when they reduced the fees which I thought was nice of them) and I find it far better than just web surfing.
The content is, of course, fantastic. They have the usual printer-friendly formatting (though the pics don't work) and they have links from each article to web content.
One of the most important points is that made above -- that the content is more reliable than the web as returned by a search engine. It is provided by authorities in the field, it is reviewed, it is well cross-referenced and it is well edited.
Of course, free access for everyone to such a source of knowledge outweighs by far the disadvantage to me of having to see ads but I suspect I will miss the days without them.
The above statements on RC4 are entirely true. It is worth noting, however, that an algorithm called ARCFOUR is an internet draft (possibly RFC by now) before the IETF. As the name implies, it is a description of an RC4 compatible algorithm. I believe it is proposed by Rodney Thayer of the IPSEC community.
In any case, RC4 is less useful than RC2 in contexts other than TLS since it is a stream cipher and therefore rather harder to use securely.
My company has done extensive research into the issue of the RSA patent and has talked to many other companies in the field. We are certain that the expiry of the patent in September will leave RSA as used in modern protocols totally unencumbered.
While, DSA and DH-EG are very good algorithms, each has its own quirks and you still need two sets of keys. Whil ehaving separate signing and encryption keys is very good security practice, it can be inconvenient for some sets of applications. In addition, RSA is by far the most widely implemented algorithm and so it is very important for interoperability between implementations and across standards. The Thawte example above is quite common in the PKI industry.
It is worth noting that an industry rumour has it that RSADSI make about 50% of their money from litigation, 25-30% from the RSA conference (now really a trade show), 10% from patent licensing and the rest from licensing of toolkits. Of course, this is entirely hearsay.
In fairness to RSA, they do at least appear to plough a lot of this money back into research through RSA Labs who do a lot of important work.
We've been using Samba since '95 when it was recommended to me by the sysadmin in Iona Tech. Apart from some flakiness around DST on the older versions (which really pissed off the developers) it's been great and saved us a fortune. It really is amazing the performance you can get from fairly generic machines.
This is not twofish or loki or any of the other AES candidates because it isn't a symmetric block cipher. It's asymmetric. Incidentally, Sarah is well aware of the issues in the general area. Everyone knows that an algorithm needs peer review etc, even if it doesn't have any other disadvantages etc.
I refer everyone (as usual) to Bruce Schneier's excellent Crypto-gram in October edition/episode of which he talks about the number of new algorithms proposed each day (this generations Fermat's Last Theorem?)
Enjoy,
Keith -- Keith Brady, Baltimore Technologies, IFSC House, Custom House Quay, Dublin 1, Ireland
Slashdot Mirror
You use isle where you mean aisle and you leave in user's where you mean users.
Sharp
I'm moving all of our development machines (running FC) and servers (running RedHat) to Centos. I got fed up with the terrible bandwidth available to RedHat up2date users (for $350 per machine per year I expect to get the bandwidth I need to update infrequently) and the lack of cheap centralised mangement.
With Centos (and other apt/yum based clones) I can set up a local repository and save the network the trouble.
Also it would definitely simplify your weight distribution. I prefer integrated weights (being overweight I am very bouyant and so need a lot) and , in conjunction with a tank, they can definitely cause a lot of BCD inertia.
Of course, I'm wondering how well all those neat holds you learn in PADI Rescue will work without a big tank stem/First Stage to grab.
Try setting up a proper security architecture for it using SASL and/or TLS to support samba and pam SSO.
I know LDAP very well and have worked with many different servers but trying to find the exactly correct version of openldap to support properly secured passwords for samba manager and root in the DIB was a nightmare. I eventually gave up and had to go back to the security requirements phase to get around it.
As for hoping to train up the less experienced admins on the system, I was pretty sure that would never be possible.
I thought the
Certainly caused a lot of hassle though, not to mention the French restrictions on even doing crypto. I'm glad they've both changed.
A single RSA key can be used for both signing and encryption (thought he wisdom of this is debatable).
RSA keys are far smaller than DH-EG ones.
RSA signature verification (the most commonly performed operation in the real world) is far faster than DSA.
RSA is far more widely deployed than DSA and especially DH-EG.
The whole point of a patent is that it is anti-competitive. It is there to protect you from competition so that you are encouraged to publicise the work.
There was no patent outside the US. The company I work for produced its products in US and rest-of-world flavours only.
As is widely known, trademarks usually only apply to a single category and a in the countries they are registered in.
Coca-Cola are in the fortunate position of having some of the very, very few trademarks which apply across the categories. Coca-Cola and Coke are both trademarks and both are recognised in this manner.
In addition, as noted in the discussions, a Swiss person might reasonably expect coke.ch to refer to a Coca-Cola site whereas cocaine.ch would meet the requirements for a cocaine site perfectly. It is surprising that Sitzerland has no
I work for a crypto company too and I concur with the above statement. While there are asymmetric stream algorithms (RPK is the main one, I believe) most of the existing knowledge is of using asymmetric algorithms to share session keys for stream ciphers. It is always good idea to go with the most used algorithms unless there are known deficiencies in them. See any of Bruce Schneier's Cryptogram newsletters for reasons (http://www.counterpane.com).
Two points:
1) It is better to use a real stream cipher (such as RC4/Arcfour or one of the LFSR based ones) since they all emit a single byte at a time and are very fast. Key entropy is not necessarily a problem with the LFSR based ones since you will be generating the session keys automatically (must be from a good PRNG). CBS-mode block algorithms are fine too but the performance will usually leave something to be desired.
2) ALWAYS generate a new session key for each encryption session and preserve state for the duration of the session. NEVER start a new stream with the same key or reset the state to the initial value in mid-stream (e.g. for resynchronisation). If you get this wrong you might as well send it all in clear (since the XOR attacks are basically trivial).
I find that most things I want to do with CGI benefit greatly from Perl's fast, simple text handling. The need to roll your own versions of the standard Perl text mangling functions really puts me off.
That said, I did reimplement a pretty big Perl CGI in C a while back, in part for speed but mainly because it had to go in with a C based backend suite and the developers didn't know Perl and so couldn't support the old CGI.
I agree with these comments. I've been using online EB for just over a year now (they extended my membership to eighteen months when they reduced the fees which I thought was nice of them) and I find it far better than just web surfing.
The content is, of course, fantastic. They have the usual printer-friendly formatting (though the pics don't work) and they have links from each article to web content.
One of the most important points is that made above -- that the content is more reliable than the web as returned by a search engine. It is provided by authorities in the field, it is reviewed, it is well cross-referenced and it is well edited.
Of course, free access for everyone to such a source of knowledge outweighs by far the disadvantage to me of having to see ads but I suspect I will miss the days without them.
The above statements on RC4 are entirely true. It is worth noting, however, that an algorithm called ARCFOUR is an internet draft (possibly RFC by now) before the IETF. As the name implies, it is a description of an RC4 compatible algorithm. I believe it is proposed by Rodney Thayer of the IPSEC community.
In any case, RC4 is less useful than RC2 in contexts other than TLS since it is a stream cipher and therefore rather harder to use securely.
My company has done extensive research into the issue of the RSA patent and has talked to many other companies in the field. We are certain that the expiry of the patent in September will leave RSA as used in modern protocols totally unencumbered.
While, DSA and DH-EG are very good algorithms, each has its own quirks and you still need two sets of keys. Whil ehaving separate signing and encryption keys is very good security practice, it can be inconvenient for some sets of applications. In addition, RSA is by far the most widely implemented algorithm and so it is very important for interoperability between implementations and across standards. The Thawte example above is quite common in the PKI industry.
It is worth noting that an industry rumour has it that RSADSI make about 50% of their money from litigation, 25-30% from the RSA conference (now really a trade show), 10% from patent licensing and the rest from licensing of toolkits. Of course, this is entirely hearsay.
In fairness to RSA, they do at least appear to plough a lot of this money back into research through RSA Labs who do a lot of important work.
I would recommend the Amanda backup system which we have used in work for many years and can deal nicely with these problems.
We've been using Samba since '95 when it was recommended to me by the sysadmin in Iona Tech. Apart from some flakiness around DST on the older versions (which really pissed off the developers) it's been great and saved us a fortune. It really is amazing the performance you can get from fairly generic machines.
This is not twofish or loki or any of the other AES candidates because it isn't a symmetric block cipher. It's asymmetric. Incidentally, Sarah is well aware of the issues in the general area. Everyone knows that an algorithm needs peer review etc, even if it doesn't have any other disadvantages etc.
I refer everyone (as usual) to Bruce Schneier's excellent Crypto-gram in October edition/episode of which he talks about the number of new algorithms proposed each day (this generations Fermat's Last Theorem?)
Enjoy,
Keith
--
Keith Brady,
Baltimore Technologies,
IFSC House, Custom House Quay,
Dublin 1, Ireland
You surely aren't going to get laid thinking like that. It can't be the case that all the cute, smart, American women are here in Europe.