Re: blocking chinese domains?
On 29 Jun 2001, John R. Levine wrote: In article l0311071bb76193cbb497@[208.192.101.177] you write: does anyone know whether china has recently shut down its citizens' outgoing network access? I gather that for quite a while, Chinese networks have been behind what's known as the Great Firewall of China, and it does indeed filter sites the government doesn't like. May be this is also the reason why some smart people in China have started to mirror interesting-to-them but sensible-in-content sites? My own collection of cryptographic pointers, http://www.tml.hut.fi/~helger/crypto/ has been mirrored a while as http://infosec.cs.pku.edu.cn/~tly/helger-crypto/ - and I know it is not the only popular site; they have e.g. mirrored the cryptographic part of the Counterpane webpage. Although I am not sure this has been done since they wouldn't be able to access the sites otherwise... My original pages have received some hits from China during THIS weekend. Helger - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Press Release List] IBM and Zero-Knowledge Systems: A sharedVision For Privacy
--- begin forwarded text From: Craig Silverman [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: [Press Release List] IBM and Zero-Knowledge Systems: A shared Vision For Privacy Date: Fri, 29 Jun 2001 17:07:26 -0400 Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] == The Zero-Knowledge Systems Press Release http://www.zeroknowledge.com == FOR IMMEDIATE RELEASE IBM Announces An Enterprise Privacy Architecture Protecting Brand, Building Customer Trust And Adding Business Value Through Privacy Protection SOMERS, NY -- 06/29/2001 -- IBM today unveiled a comprehensive Enterprise Privacy Architecture (EPA) to address the complex privacy challenges facing 21st century businesses, governments and other organizations. The patent-pending EPA provides a road map for privacy management and solutions to help companies protect customer, employee and partner information. The Enterprise Privacy Architecture we're announcing today is a significant privacy and business development. It affords organizations a framework for efficiently imbedding their privacy requirements into every level of the business, while integrating with existing e-business initiatives, said Mike Bilger, global practice leader, security and privacy, IBM Global Services. This architecture responds to business demand for tailored enterprise privacy controls. It is designed to help organizations manage and protect their three most vital assets -- data, customer relationships, and brand. IBM's privacy blueprint balances growing needs for information with the privacy concerns of individuals, thereby permitting integration of business and external privacy rules, customer preferences, and privacy best practices into line-of-business and customer-centric business processes. IBM developed the EPA in response to client needs to move privacy beyond policy and to align IT and management to make privacy work for businesses and their customers. IBM's Tivoli Systems management team has been key contributors to the EPA, and our Tivoli SecureWay Privacy Manager product serves as a major component of the EPA road map initiative, said Jeff Smith, Senior Vice-President, Application Products, Tivoli Systems Inc. Combining the EPA with Tivoli SecureWay Policy Director and Tivoli SecureWay Privacy Manager, security and privacy policies can be monitored and enforced consistently across the enterprise. Zero-Knowledge Systems' Privacy Rights Management (PRM) technologies will complement IBM's EPA, and help accelerate industry's ability to implement the EPA vision. Zero-Knowledge(r) Systems' Privacy Rights Management technologies, in concert with IBM's EPA, will for the first time provide businesses with the privacy tools, methodology and expertise required to close the gap between stated policies, customer preferences and operational realities, said John Beans, Vice-President, Product Marketing, Enterprise Products, Zero-Knowledge Systems. The development of the EPA is based on the growing number of companies that understand privacy as an essential element to cultivating strong relationships by using information effectively and appropriately. The EPA takes organizations a step further by helping to transform privacy from a cost of doing business to a business value with strong return on investment (ROI). The combination of the EPA blueprint and consulting services, together with the technology capabilities of companies like Tivoli and Zero-Knowledge Systems, will enable leaders around the world to approach the privacy challenge strategically and efficiently, said Harriet Pearson, Chief Privacy Officer, IBM. Through a mix of consulting methodology and technology integration, the EPA aligns corporate-level policy with practices and appropriate technologies through rigorous EPA-based analysis of infrastructure, processes, information flows, and practices. EPA identifies selected privacy risks and opportunities to improve core business functions across an enterprise. EPA can also be used assist enterprises in addressing and leveraging privacy for e-business initiatives such as customer relationship management and business intelligence implementations. An important part of the EPA privacy ROI is in its scalability, flexibility and ability to leverage the best privacy-enabling technologies available in the marketplace today -- such as those from Tivoli and Zero-Knowledge Systems. The Enterprise Privacy Architecture was designed by a cross-IBM team, including expert privacy consultants from IBM's Privacy Center of Competence, representatives of IBM's Research Division, IBM's Chief Privacy Officer, and Tivoli Systems, alongside IBM's knowledge management and pervasive computing teams and its customer database management group. IBM Security and Privacy Consulting is part of IBM Global Services, the world's
Re: Crypographically Strong Software Distribution HOWTO
On Mon, Jul 02, 2001 at 04:37:00PM -0400, Rich Salz wrote: I've written a HOWTO on the cryptographically strong distribution of computer software. Any constructive criticism would be appreciated. Seems pretty nice; thanks for doing this. Any chance of using SHA1 instead of MD5? MD5 seems to have weaknesses; the IETF says not to use it in their protocols, for example. Any references for either the weaknesses of md5, or what the IETF has to say on the issue? -- Kent Crispin Be good, and you will be [EMAIL PROTECTED] lonesome. -- Mark Twain - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
In our last episode (Re: Crypographically Strong Software Distribution HOWTO, shown on 7/2/01), Kent Crispin said: Any references for either the weaknesses of md5, or what the IETF has to say on the issue? Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie references, a note by Dobbertin on the issue: http://www.math.ohio-state.edu/~fiedorow/PGP/MD5_discussion and his paper on the weaknesses: http://www.cs.ucsd.edu/users/bsy/dobbertin.ps The short answer is that he found weaknesses in MD5 similar to the weaknesses found in MD4 before it was broken. The message since then has been don't panic, but use a newer algorithm for new work. (In fact, the Dobbertin note above says not to panic, but start looking for better algorithms.) The answer is that you SHOULD (in IETF terms, see RFC 2119, http://www.ietf.org/rfc/rfc2119.txt for a definition of MAY, SHOULD, MUST, etc.) use SHA-1. In plain language, what this means is that if you don't know when to use MD5 and when to use SHA1, then use SHA1. If you pick MD5, be prepared to answer people when they ask why you did. If for some reason you don't want to use SHA1, look at RIPE-MD160. If you don't like either of them, there are other choices, but we now start getting into subtlety and taste. On the other hand, in the intervening five years, we haven't seen a break in MD5 appear. So maybe it's not as bad as we thought. Nonetheless, if you have a choice and you don't know what to do, pick SHA1. At the very least, no one will send you an email that starts, Why did you use MD5? Don't you know that Hans Dobbertin Jon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
On Mon, 2 Jul 2001, Jon Callas wrote: The answer is that you SHOULD (in IETF terms, see RFC 2119, http://www.ietf.org/rfc/rfc2119.txt for a definition of MAY, SHOULD, MUST, etc.) That document clarifies nothing, it might as well say the following - 1. MUST This word, or the terms REQUIRED or SHALL, mean that the anyone violating the definition is a BAD PERSON. 3. SHOULD This word, or the adjective RECOMMENDED, mean that anyone violating the definition might or might not be a BAD PERSON. On the other hand, in the intervening five years, we haven't seen a break in MD5 appear. So maybe it's not as bad as we thought. Nonetheless, if you have a choice and you don't know what to do, pick SHA1. At the very least, no one will send you an email that starts, Why did you use MD5? Don't you know that Hans Dobbertin Most applications which move around files identify them by sha1 hash, so if you use sha1 you might be able to use interoperability at some point. With md5 that isn't a possibility. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Jon Callas wrote: Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie references, a note by Dobbertin on the issue: http://www.math.ohio-state.edu/~fiedorow/PGP/MD5_discussion and his paper on the weaknesses: http://www.cs.ucsd.edu/users/bsy/dobbertin.ps The short answer is that he found weaknesses in MD5 similar to the weaknesses found in MD4 before it was broken. ... Also note that RFC 2104 on the HMAC construction used in IPSEC explicitly cites Dobbertin and says the attack does not apply: ... MD5 has been recently shown to be vulnerable to collision search attacks [Dobb]. This attack and other currently known weaknesses of MD5 do not compromise the use of MD5 within HMAC as specified in this document - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
I've written a HOWTO on the cryptographically strong distribution of computer software. Any constructive criticism would be appreciated. I hope to standardize the use of this model in the GNU/Linux free software community. You can find the HOWTO here: http://www.cryptnet.net/fdp/crypto/strong_distro.html Thanks, - VAB I have another quibble with what is a really good start on a HOWTO. You say in your section on anonymous software development groups, The identity of the maintainer is established through the possession of the secret key of a project key pair, therefore possession of the secret key could be presented as proof in a courtroom as evidence that an individual is a maintainer or developer in a Guerrilla development project. This evidence would be very difficult to refute in court. The only possible argument that could be used to deny authorship would be to state the the secret key was stolen. However, typeo === that the theft of a secret key suggest other felony crimes where committed. To a lesser extent, possession of the revocation certificate has similar ramifications. If the secret key and/or revocation certificate was widely distributed, say by being posted to the cypherpunks mailing list, it seems unlikely that mere possession would constitute strong proof of membership in the development group. If the key becomes widely distributed, the development group must immediately take steps to establish the reputation of a new key. There might be an interesting scramble between the development group, and other group(s) wishing to obtain the reputation of the development group. Cheers - Bill - Bill Frantz | The principle effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Crypographically Strong Software Distribution HOWTO
Hans Dobbertin found some weaknesses in MD5 in 1996. Also note that RFC 2104 on the HMAC construction used in IPSEC explicitly cites Dobbertin and says the attack does not apply: this is because dobbertin's attack works only against message-digest applications of md5; his attack doesn't work against md5 MACs, ie, when md5 is used to hash a symmetric key with the plaintext. but, i generally tell clients to use sha-1 even for MACs, just to avoid confusing their customers. - don davis, boston - - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: [JXTA Security] Anonymity Snake Oil in JXTA
Philippe Coupe wrote: Here is some answer to Ben Laurie legitimate questions (sorry for the delay but I was off last week) ... [...]They have chosen (by what process?) a thing called EPocketCash (http://www.epocketcash.com/[1]) to do this[...] JXTA neither SUN did not chose to implement EPocketCash. I, as CEO of IPassport Corporation (who operates EPocketCash) proposed to the JXTA governance to implement our payment system (inside JXTA). Again, we will implement the JXTA merchant and client parts of our payment system. The source code will be fully available and will follow open source licence guidelines set by JXTA governance. If you want to create another payment system project you are free to propose and implement it yourself... Later, the market will decide (and not you, me or JXTA community/governance) ... OK, this has been pointed out by a few other people. It should be _much_ clearer on the website. [...] it is tied to bank accounts [...] You like it or not but, worldwide, banks manage the money. Without a bank accout there is no way to put money to/from any payment system of anykind. A payment system is only a process to debit/credit a bank account. Oh yeah? So what are these banknotes and coins in my pocket, then? With EPocketCash, this account is not a regular account or a checking account but an EPocketCash/Your_Bank (co-branded like your VISA card) account opened at this branch of this bank (of course it must be a bank who partner with us). Your checking/saving (or any existing) account are not linked to your EPocketCash account... So can I open one without presenting ID? Can I transfer cash into one without ID? [...]Oh, except a judge[...] Like it or not but we are a US corporation and as such we have to follow the laws and regulations of the USA. And those do _not_ state that you are required to track money. [...]Oh, and probably either side of the transaction (so they can take you to court, see? Isn't that a marvellous benefit? [well, they told me it was, and they should know, right?]) [...] No, the merchant never know the identity/account number of the client. Test our technology yourself as a client and as a merchant and check it yourself. Through JXTA, try to understand the system and if needed, help us fix it... So how do I get to take legal action against the merchant as you described? How does a merchant take action against a fraudulent client? Remember, here, we all work on the JXTA project and it's a community based work... So publish your technical documentation, in its entirety. Cheers, Ben. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Ben Laurie Sent: Thursday, June 28, 2001 7:43 PM To: Coderpunks; Cryptography; UKCrypto Cc: JXTA Security Subject: [JXTA Security] Anonymity Snake Oil in JXTA JXTA (http://www.jxta.org/) claims to have a payment project which will implement anonymous and secure financial transactions. See: http://payment.jxta.org/servlets/ProjectHome They have chosen (by what process?) a thing called EPocketCash (http://www.epocketcash.com/[1]) to do this. Here's the marketing droidlish: The goal is to implement the Epocketcash payment protocol for financial transactions for JXTA. EPocketCash is the first payment system designed exclusively for the Internet. It allows anybody to be a merchant and/or a customer at the same time with the same account. This anonymous payment system will work on any gizmos connected to the internet. Currently we support the WEB, WAP and I-Mode phones. Sounds great, no? There's just one teeny problem. It isn't anonymous. Not even a little bit. It is merely secret. That is, it is tied to bank accounts, and they promise (no, really) that they won't tell anyone who you are. Oh, except a judge. Oh, and probably either side of the transaction (so they can take you to court, see? Isn't that a marvellous benefit? [well, they told me it was, and they should know, right?]). Oh, and anyone who breaks into their system. But it is anonymous really. They said so. Cheers, Ben. [1] I can't actually read this, it renders horribly on Netscape, but my information comes from Philippe Coupe, President and CEO of IPassport Corp (who own EPocketCash?). -- http://www.apache-ssl.org/ben.html In Boston 'til 1st July. -- http://www.apache-ssl.org/ben.html There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
