Re: Security Architect Position at National Archives
At 12:02 PM -0400 4/29/04, Rich Salz wrote: The role is for a system architec/designer with strong cyber security experience. Somebody who can evaluate the security implication of various design proposal. In other words, I'm not looking just for somebody who can run a firewall or vulnerabiility check, or who can cite NIST security standard (although those skills woul dcome in handy too!). i talked to them. the downside is that they want this security architect to be the security administrator, once the system is built... - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases
hi, mr. reinhold -- there's stronger reason than the ones you cite, to distrust md5 as a message-digest. see these old sci.crypt threads, and the google-search below, for discussions of hans dobbertin's 1996 crack of md5: http://tinyurl.com/2ox7g http://tinyurl.com/3x446 http://google.com/search?q=dobbertin+md5num=30 btw, in a phone conversation, dobbertin emphasized to me that his attack only works when md5 is used as a message-digest; it doesn't work when md5 is used with a key to prepare a MAC. he also mentioned that while sha-1 may be vulnerable to an attack of a similar style (because sha-1 is similar in struc- ture to md5), he himself was forbiddden by german law to work to cryptanalyze sha-1, because he worked at that time for the german federal security service, and so wasn't allowed to attack the USG's standard ciphers. now he's at ruhr university (in bochum), but i don't know whether he's more of a free agent. - don davis, boston To: [EMAIL PROTECTED] From: Arnold G. Reinhold [EMAIL PROTECTED] Subject: [Mac_crypto] Apple should use SHA! (or stronger) to authenticate software releases Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] List-Id: Macintosh Cryptography mac_crypto.vmeng.com List-Archive: http://www.vmeng.com/pipermail/mac_crypto/ Date: Sun, 4 Apr 2004 06:17:55 -0500 The cryptographic hash function MD5 has long been used to authenticate software packages, particularly in the Linux/Unix/open source community. This has carried over to Apple's OS-X. The MD5 hash of an entire package is calculated and its value is transmitted separately from the package. Users who download the package compute the hash of the copy they received and match that value against the original. ... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Monoculture
perry wrote:
We could use more implementations of ssl and
of ssh, no question.
...more cleanly implemented and simpler to use
versions of existing algorithms and protocols...
would be of tremendous utility.
jill ramonsky replied:
I am very much hoping that you can answer both (a)
and (b) with a yes, in which case I will /definitely/
get on with recoding SSL:
Is it possible for Bob to instruct his browser to
(a) refuse to trust anything signed by Eve, and
(b) to trust Alice's certificate (which she handed
to him personally)? (And if so, how?)
how it's done depends on the browser:
in Moz 1.0: Edit Preferences... Privacy Security
Certificates Manage Certificates
{Authorities, Web Sites}
in MSIE 5: Edit Preferences.., Web Browser
Security Certificate Authorities
(there seems to be no way to tell MSIE 5 to
trust Alice's server cert for SSL connections,
except to tell MSIE 5 to trust Alice's CA.)
in NS 4.75: Communicator Tools Security Info
Certificates {Signers, Web Sites}
- don davis, boston
-
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
EKR writes: I'm trying to figure out why you want to invent a new authentication protocol rather than just going back to the literature ... there's another rationale my clients often give for wanting a new security system, instead of the off- the-shelf standbys: IPSec, SSL, Kerberos, and the XML security specs are seen as too heavyweight for some applications. the developer doesn't want to shoehorn these systems' bulk and extra flexibility into their applications, because most applications don't need most of the flexibility offered by these systems. some shops experiment with the idea of using only part of OpenSSL, but stripping unused stuff out of each new release of OpenSSL is a maintenance hassle. note that customers aren't usually dissatisfied with the crypto protocols per se; they just want the protocol's implementation to meet their needs exactly, without extra baggage of flexibility, configuration complexity, and bulk. they want their crypto clothing to fit well, but what's available off-the-rack is a choice between frumpy one-size-fits-all, and a difficult sew-your-own kit, complete with pattern, fabric, and sewing machine. so, they often opt for tailor-made crypto clothing. my clients' concern (to keep their crypto code as small and as simple as possible) doesn't justify their inventing and deploying broken protocols, but their concern does point out that neither the crypto industry nor the crypto literature has fully met these customers' crypto needs. - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Monoculture
eric wrote: The way I see it, there are basically four options: (1) Use OpenSSL (or whatever) as-is. (2) Strip down your toolkit but keep using SSL. (3) Write your own toolkit that implements a stripped down subset of SSL (e.g. self-signed certs or anonymous DH). (4) Design your own protocol and then implement it. Since SSL without certificates is about as simple as a stream security protocol can be, I don't see that (4) holds much of an advantage over (3) i agree, except that simplifying the SSL protocol will be a daunting task for a non-specialist. when a developer is faced with reading understanding the intricacy of the SSL spec, he'll naturally be tempted to start over. this doesn't exculpate the developer for biting off more than he could chew, but it's unfair to claim that his only motivation was NIH or some other sheer stupidity. btw, i also agree that when a developer decides to design a new protocol, he should study the literature about the design analysis of such protocols. but at the same time, we should recognize that there's a wake-up call for us in these recurrent requests for our review of seemingly-superfluous, obviously-broken new protocols. such developers evidently want and need a fifth option, something like: (5) use SSSL: a truly lightweight variant of SSL, well-analyzed and fully standardized, which trades away flexibility in favor of small code size ease of configuration. arguably, this is as much an opportunity as a wake-up call. - don davis - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: traffic analysis of phone calls?
Slightly off-topic, but a reminder of the sort of thing that ordinary crypto doesn't hide. http://www.silicon.com/news/59-51/1/5093.html?rolling=2 IT Myths: Colombian drugs gang's mainframe-assisted assassinations? Did drugs barons really use multi-million pound systems to see who was grassing to informants...? with similar import, here's cringely's article on insecure CALEA workstations: - don davis http://www.pbs.org/cringely/pulpit/pulpit20030710.html Not only can the authorities listen to your phone calls, they can follow those phone calls back upstream and listen to the phones from which calls were made. They can listen to what you say while you think you are on hold. This is scary stuff. But not nearly as scary as the way CALEA's own internal security is handled. The typical CALEA installation on a Siemens ESWD or a Lucent 5E or a Nortel DMS 500 runs on a Sun workstation sitting in the machine room down at the phone company. The workstation is password protected, but it typically doesn't run Secure Solaris. It often does not lie behind a firewall. Heck, it usually doesn't even lie behind a door. It has a direct connection to the Internet because, believe it or not, that is how the wiretap data is collected and transmitted. - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
google crypto?
does anyone know anything about AP's claim that Google encrypts credit-card numbers? specifically, which cipher and what kind of key management do they use? - don davis, boston - From: Google puts new gadgets in browser Friday, June 27, 2003 http://www.cnn.com/2003/TECH/internet/06/27/google.gadgets.ap/index.html The new software out Thursday for the [Google] toolbar includes ... a program that automatically fills out Internet forms seeking a customer's name and address. The function that fills in forms offers an option to store credit card numbers too, but the information is encrypted on the hard drive of a user's computer instead of Google's computers, for security and privacy reasons. - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
