Re: Do You Need a Digital ID?
minor addenda ... ref: http://www.garlic.com/~lynn/aadsm19.htm#1 Do You Need a Digital ID? http://www.garlic.com/~lynn/aadsm19.htm#2 Do You Need a Digital ID? there are 2nd order implementations of public/private key authentication business process where keeping the private key private might involve * keeping the private key in an encrypted file and a pin/password is required to decrypt a file. this could be considered a possibly weak form of two-factor authentication: 1) possession of the encrypted file and 2) possession of the key to decrypt the file (it may in fact be considered so weak that many might considerd it only one-factor authentication, the knowledge of the key to decrypt the file). * keeping the private key in a token ... where the characteristics of the private key and the token holding the private key are taken as equivalent. the simple token/private-key equivalence is then one-factor something you have authentication ... aka a) digital signature is an expression of access and use of the private key and b) access and use of the private key is an expression of the possession of the token. * a private key token that requires PIN and/or biometrics to operate in specific manner ... a relying party with business process certification of the private key only existing in a specific token and that the specific token is also certified as to requiring specific PIN and/or biometrics then possibly the relying party can assume some form of two factor authentication (or even three factor authentication); the digital signature is an expression of the access and use of the private key, the access and use of the private is an expression of a combination of a) possession of a specific hardware token, b) corresponding PIN for that specific hardware token to operate in a specific manner and/or c) biometric for that specific hardware token to operate in a specific manner. note in the old fashion identity digital certificates from the early 90s ... there was frequently little or no discussion as to the integrity requirements regarding the ability to access and use a specific private key (which is what the whole private/public key business process is fundamentally built on). there was frequently lots of documentation on what a certification authority might do in the integrity around the generation of an identity digital certificate but very little or nothing about what the key owner was required to do in order to enable the whole fundamental public/private key business process to operate correctly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
now, i've said that all of these comments are within the 3 factor authentication paradigm ... if you back up a couple paragraphs in the original postings ... you will find the comments: given 3-factor authentication: * something you have * something you know * something you are aka the comments/postings are within the framework/paradigm of 3-factor authentication. so is the issue with the 3-factor authentication framework ... or is the issue that the comments are inconsistent given a 3-factor authentication framework? I assert (as stated in the original posting) that the comments/posting is within the context of 3-factor authentication framework and the definition of the public/private key business process. you are free to define something other than 3-factor authentication framework or a totally different business process for the treatment of asymmetric cryptography keys. a digital signature is something that is supposedly hard to counterfeit and just represents the application of a private key to some data (the digital signature is an indication/expression that a private key has been accessed and used). for most entities, a private key is not something that is memorized, but rather it is contained by something that the human has. the integrity of the process is based on the integrity of the infrastructure that controls the access and use of that private key ... therefor a digital signature infrastructure typically represents a something you have technology. the whole asymmetric cryptography technology (of which a digital signature is just a part) has been taken and a business process wrapped afound it which is frequently referred to as public/private key cryptography (an abbreviation frequently to simple public key technology). the foundation of the public/private key (or public key technology for short) business process is based on keeping the private key actually private. If everybody is allowed to have as free access to the private keys as there is access to the public key ... the whole infrastructure (including digital signatures) falls apart. So if you are looking at a threat assessement ... the public/private key business process allows for both digital signatures and public keys to be readily known ... the whole foundation that holds the whole public key business process together is based on keeping the private key actually unknown and unaccessable to others than the authorized entities. so i've haven't seen any private key deployments which are based on a human actually memorizing the private key ... so it can't be a (at least directly) a something you know operation. of the private key deployments i've seen, there has been the requirement that an entity possesses a private key and is able to access and make use of that private key ... since it isn't something you know (and since a private key is also not typically something you are biometrics) then that leaves a private key representing something you have. so if you look at typical something you have infrastructures, their integrity is based on the protection of the operations that access and utilize the something you have. as i pointed out in one of the earlier postings, much of the literature in the mid-90s grossly confused the the terms digital signature and digital certificates and private key ... to the point that it sometimes represented that a digital ceritifcate was responsible for generating a digital signature (or by implication the public key included in a digital certificate). Since the public/private key business process allows for both digital signatures and public keys to be readily known, it is fairly obvious that they can't be the integrity/security foundation for the business process. so when a digital signature is validated with a public key ... what is it doing ... it is validating that the private key (of a public/private key pair from asymmetric cryptography) generated that digital signature. private key isn't a characteristic of asymmetric cryptography ... it is a characteristic of public/private key business process requiring that the private key be kept private. a digital signature is just an expression of the business process use of that private key. so from 3-factor authentication paradign there are three things: * something you know authentication * something you have authentication * something you are authentciation now, i know of no public/private key business process deployments that require humans to memorize the private key ... that eliminates (at least direct use of) something you know authentication. the most common deployments of public/private key business process deployment aren't based on biometrics ... which then eliminates something you are authentication. that just leaves private keys as a type of something you have technology ... (since it isn't memorized or biometrics). therefor the foundation of public/private key
Re: Do You Need a Digital ID?
| now, i've said that all of these comments are within the 3 factor | authentication paradigm ... if you back up a couple paragraphs in the | original postings ... you will find the comments: | | given 3-factor authentication: | | * something you have | * something you know | * something you are | | aka the comments/postings are within the framework/paradigm of 3-factor | authentication. so is the issue with the 3-factor authentication framework | ... or is the issue that the comments are inconsistent given a 3-factor | authentication framework? I don't think the 3-factor authentication framework is nearly as well-defined as people make it out to be. Here is what I've always taken to be the core distinctions among the three prongs: Something you know Can be copied. If copied illicitly, you can't tell (except by noticing illicit uses). Something you have Cannot be copied. Can be transferred (i.e., you can give it to someone else, but then you no longer have it) Hence, if transferred illicitly, you can quickly detect it. Something you are Cannot be transferred. Cannot be changed. Inherently tied to your identity, not your role. This classification, useful as it is, certainly doesn't cover the space of possible authentication techniques. For example, an RFID chip embedded under the skin and designed to destroy itself if removed doesn't exactly match any of these sets of properties: It's not something you have because it can't be transferred, but it's not something you are because it can be changed. Attempting to force-fit everything into an incomplete model doesn't strike me as a useful exercise. | I assert (as stated in the original posting) that the comments/posting is | within the context of 3-factor authentication framework and the definition of | the public/private key business process. you are free to define something | other than 3-factor authentication framework or a totally different | business process for the treatment of asymmetric cryptography keys. | | a digital signature is something that is supposedly hard to counterfeit | and just represents the application of a private key to some data (the | digital signature is an indication/expression that a private key has been | accessed and used). for most entities, a private key is not something that | is memorized, but rather it is contained by something that the human | has. the integrity of the process is based on the integrity of the | infrastructure that controls the access and use of that private key | ... therefor a digital signature infrastructure typically represents a | something you have technology. Yes, this *entire system* - a private key embedded in a device that protects the secret key embedded in it - is properly described as something you have. But people use the phrase digital signature to describe other systems as well. The laws on acceptable digital signatures are broad enough to include way more than this - in fact, way more than is really reasonable. If my secret key is stored en clair in a file on a general-purpose computer that provides no protection against copying, it still acts in some ways like something I have, but it lacks the cannot be copied attribute that seems central to the notion. On the other hand, if the secret key is stored in a file encrypted using a pass phrase that I memorize, the entire system takes on the security properties of something I know, even though it has a physical embodiment. | the whole asymmetric cryptography technology (of which a digital signature | is just a part) has been taken and a business process wrapped afound it | which is frequently referred to as public/private key cryptography (an | abbreviation frequently to simple public key technology). the foundation of | the public/private key (or public key technology for short) business process | is based on keeping the private key actually private. If everybody is | allowed to have as free access to the private keys as there is access to | the public key ... the whole infrastructure (including digital signatures) | falls apart. | | So if you are looking at a threat assessement ... the public/private key | business process allows for both digital signatures and public keys to be | readily known ... the whole foundation that holds the whole public key | business process together is based on keeping the private key actually | unknown and unaccessable to others than the authorized entities. | | so i've haven't seen any private key deployments which are based on a human | actually memorizing the private key ... so it can't be a (at least directly) | a something you know operation. of the private key deployments i've seen, | there has been the requirement that an entity possesses a private key and | is able to access
Re: Do You Need a Digital ID?
Now that the taxing bodies (US states) have learned not to print the SSN on the mailing label, Illinois has gone further and requires a state-assigned PIN to file or access your tax information over the internet. They helpfully provide you the PIN ... on the mailing label. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
Jerrold Leichter wrote: I don't think the 3-factor authentication framework is nearly as well-defined as people make it out to be. Here is what I've always taken to be the core distinctions among the three prongs: Something you know Can be copied. If copied illicitly, you can't tell (except by noticing illicit uses). Something you have Cannot be copied. Can be transferred (i.e., you can give it to someone else, but then you no longer have it) Hence, if transferred illicitly, you can quickly detect it. Something you are Cannot be transferred. Cannot be changed. Inherently tied to your identity, not your role. This classification, useful as it is, certainly doesn't cover the space of possible authentication techniques. For example, an RFID chip embedded under the skin and designed to destroy itself if removed doesn't exactly match any of these sets of properties: It's not something you have because it can't be transferred, but it's not something you are because it can be changed. Attempting to force-fit everything into an incomplete model doesn't strike me as a useful exercise. but business rules for public(/private) key infrastructure can describe that only the associated authenticating entity is the only one in possession of the private key (something you have) as a way of relating the objective of having a specific entity's exclusive ability to access and utilize a private key to three factor authentication. almost all of the existing something you have authentication objects are capable of being counterfeited to a greater or lesser degree. possibly the widest deployed something you have authentication objects are magstripe plastic cards ... and it turns out they have been proven to be remarkably easy to counterfeit/copied. the distinction between the ease or difficulty of counterfeiting/copying a magstripe plastic card vis-a-vis a private key ... depends on the level of security used to prevent it from being copied. obviously a private key can be copied with relative ease (possibly much easier than a magstripe plastic card). in general, you will find that almost all something you have authentication objects are subject to being copied ... the issue is the degree to which security processes are in place to prevent them from being copied. just because a private key ... represented by some sequence of bits can be easily copied ... when no protections are in force ... doesn't mean that there can't be security procedures put into place that would make it extremely difficult to achieve copying of a private key. most models serve a useful purpose until somebody comes up with a better or more applicable model. many of the 3-factor authentication implementations actually use some representation that allows the actual occurence to be implied by something else. for instance something you know authentication can be done as a shared-secret where both the originator and the relying party are both in possession of the shared-secret. an example are keys in symmetric key cryptography. however, it is possible to have something you know authentication where the secret is not shared. For instance if there is a hardware token that is certified to only operate when the correct PIN has been entered the PIN represents something you know authentication w/o having to share the secret with any other party (the relying party assumes that the correct PIN has been entered by a) being confident of the operation of the particular hardware token and b) the hardware token having done something known expected). similarly, biometrics systems are frequently implemented as a form of shared-secret. an entity's biometric template is registered with some relying party and subsequent transactions are authenticated by checking a new biometric template with the biometric template on file. the x9.84 biometric standard devotes a great deal to the security for centrally stored biometric templates treating them as a greater security risk than traditional something you know shared-secrets. the threat is that somebody can obtain files of registered biometric templates and be able to subsequently retransmit them electronicly attempting to impersonate the associated person. The issue in the traditional 'something you know shared-secret is that a PIN compromise can be reported and a new, replacement PIN/password created. However, it is somewhat more difficult to replace a thumb or iris when there has been a reported compromise of something you are shared secret. in any case, for all of the deployed existing authentication systems involving any one of the three factor authentication paradigms, all of the methods are vulnerable to copying to one degree or another. as a result, I would
Re: Propping up SHA-1 (or MD5)
If it's just HMAC with K = h(m) then it's currently (or just recently) been discussed on cfrg: http://www.irtf.org/cfrg/, starting here: http://www1.ietf.org/mail-archive/web/cfrg/current/msg00708.html. -- Michael On Mon, 21 Mar 2005 11:56:44 +, Ben Laurie [EMAIL PROTECTED] wrote: It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. A third is that the length of the hash is changed, which could break existing protocols. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to phase in new hash algorithms?
Steven M. Bellovin wrote: We all understand the need to move to better hash algorithms than SHA1. At a minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is the right way to go. The problem is how to get there from here. I've been rather continually pinging people, asking them for an explanation as to the design decisions of Whirlpool (namely -- it's similar but noticably not identical to AES/Rijndael, and isn't just a straightforward expansion of the block size up to 512 bits). I'm not saying anything bad about Whirlpool, but I get alot of people approaching me about the hash and I don't really know what to tell them. --Dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Security is the bits you disable before you ship
On Wed, 16 Mar 2005, Russell Nelson wrote: I've seen Dan Bernstein (and you don't get much more careful or paranoid about security than Dan) write code like this: static char line[999]; len = 0; len += fmt_ulong(line + len,rp); len += fmt_str(line + len, , ); len += fmt_ulong(line + len,lp); len += fmt_str(line + len,\r\n); Of course, the number of characters that fmt_ulong will insert is limited by the number of bits in an unsigned long, and both strings are of constant length. Ick. Why not the simpler/clearer (and hence safer -- complexity makes it harder to find bugs of any sort, including security ones) snprintf() call: #define N_LINE 999 static char line[N_LINE]; len = snprintf(line, N_LINE, %ul , %ul\r\n, rp, lp); snprintf() first appeared in 4.4BSD and is now in C99, so any modern system should support it by now. ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Propping up SHA-1 (or MD5)
Ben Laurie writes: It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) Yes. Suppose we use this for signing. The crucial part is to have the *signer* choose the Random value when computing the signature. This may be secure even if H fails to be collision-resistant, because even if an attacker finds a collision for H, he doesn't know which Random value the signer is going to use. More generally, we could try to use any universal one-way hash function (UOWHF). This concept is also known as target collision resistant (TCR). It is natural to conjecture that H' is a UOWHF, i.e., is TCR, and this may be true even if H is not collision-resistant. Of course, there is no proof of this, and this conjecture is speculative, but it does weaken the assumptions we are making about our hash. I have been advocating this kind of construction ever since hearing about the hash cryptanalysis results last August. Not everyone agrees with me, and there is a lengthy discussion going on about this on the IRTF CFRG working group. http://www1.ietf.org/mail-archive/web/cfrg/current/threads.html http://www1.ietf.org/mail-archive/web/cfrg/current/thrd2.html http://www1.ietf.org/mail-archive/web/cfrg/current/thrd3.html However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). No, not if you use it right. The way to use this is to have the signer choose the value of Random, not anyone else. A signer can play with Random and maybe find collisions M,M', but in this case the signer will be viewed as having signed both M and M', so this doesn't help the signer at all. Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. Shouldn't be a big deal for signing. A much bigger deal is that this changes the on-the-wire format. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Time for a second thought about SDLH
On Sun, 20 Mar 2005, Steven M. Bellovin wrote: Dominated? No, of course not. But a hash function based on discrete log will be slow enough that no one will use it. This is simply not true, because we are _not always_ going to sign megabytes, and SDLH is more than fast enough for sensibly crafted texts. At the end of the day we might consider the option that we don't need a single hash function for everything. There is a place for a high end hash function. I insist on a second thought. Kind regards Ralf Senderek *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.* * Ralf Senderek [EMAIL PROTECTED] http://senderek.com* What is privacy * * Sandstr. 60 D-41849 Wassenberg +49 2432-3960 * without * * PGP: AB 2C 85 AB DB D3 10 E7 CD A4 F8 AC 52 FC A9 ED *Pure Crypto? * 49466008763407508762442876812634724277805553224967086648493733366295231438448 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: how to phase in new hash algorithms?
Steven M. Bellovin [EMAIL PROTECTED] writes: We all understand the need to move to better hash algorithms than SHA1. At a minimum, people should be switching to SHA256/384/512; arguably, Whirlpool is the right way to go. The problem is how to get there from here. So -- what should we as a community be doing now? Kick it upstairs to the political layer. Someone else's problem, we've already shown them what the solution is, our job is done. Peter :-). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Propping up SHA-1 (or MD5)
Dan Kaminsky wrote: Ben, x can equal either test vector released by Wang, and H(x) will be identical. With H(x) identical, the rest of the HMAC stays identical too. This does not appear to be correct - in my construction, i.e. without padding, then the fact that x and x' differ means that the first blocks are different, but not the colliding kind of different (since the first blocks will be 20 bytes of H(x) and blocksize-20 bytes of x or x' [or, to be pedantic, the first 20 bytes of the next block will be different]). Even if padding were included, x and x' would still not collide, because the chaining values would not be as needed at the start of the second block. As a couple people pointed out, it's OK that HMAC is vulnerable to the Wang attack, since in order to execute the attack the key is required (and like AES, if the key is compromised, all bets are off). But you're not using HMAC as a MAC; you're using it to prop up a broken hash. Regarding the Random appendage, people don't seem to realize how important syncronized initial states are to many hashing algorithms. One of the major uses of a hashing algorithm is to act as an *exchangable* handle to data, in other words, you and I can both hash our respective datasets and see if they're identical. If we're each using different initial states, that process fails utterly. Obviously. But I don't understand your point. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
FSTC-FS/ISAC Survey on Use of Encryption
--- begin forwarded text From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: FSTC-FS/ISAC Survey on Use of Encryption Date: Tue, 22 Mar 2005 05:16:10 -0600 Colleagues, FSTC and FS/ISAC have teamed together to conduct a survey on the use of encryption in the financial services sector. The survey is being sent to member-FS/ISAC and FSTC institutions and industry technology providers. The results of the survey will be combined and posted to the FSTC and FS/ISAC sites for all members. The purpose of this survey is to benchmark current security controls among FSTC and FS/ISAC members. Your input is totally voluntary and will be anonymous. All results must be posted by end-of-day Friday, March 25, 2005, when the survey will close. Thank you for your participation. Please contact me with any questions. Here is a link to the survey: http://www.surveymonkey.com/s.asp?A=67540432E27560 Regards, Zach Tumin Executive Director FSTC Please note: If you do not wish to receive further emails from us regarding this survey, please click the link below, and you will be automatically removed from the survey mailing list. http://www.surveymonkey.com/r.asp?A=67540432E27560 --- end forwarded text -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
DOT neg rulemaking re ID standardization (call for membership of advisory committee)
[Here's where an unconstitutional National ID will get created by the back door. Do we have anybody in this community who cares? I can't participate, because I can't travel to Washington for meetings, because I don't have the proper ID documents. I note that they did not think to include a representative of undocumented people... -- John] [Federal Register: February 23, 2005 (Volume 70, Number 35)] [Proposed Rules] [Page 8756-8761] From the Federal Register Online via GPO Access [wais.access.gpo.gov] [DOCID:fr23fe05-18] === --- DEPARTMENT OF TRANSPORTATION Office of the Secretary 49 CFR Subtitle A [Docket No. OST-2005-20434] Driver's Licenses and Personal Identification Cards AGENCY: Office of the Secretary (OST), DOT. ACTION: Notice of intent to form a negotiated rulemaking advisory committee. --- SUMMARY: Pursuant to the portion of the Intelligence Reform and Terrorism Prevention Act of 2004 known as the 9/11 Commission Implementation Act of 2004, the Office of the Secretary, DOT, is establishing a committee to develop, through negotiated rulemaking procedures, recommendations for minimum standards to tighten the security for driver's licenses and personal identification cards issued by States, in order for these documents to qualify for use by Federal agencies for identification purposes. The committee will consist of persons who represent the interests affected by the proposed rule, i.e., State offices that issue driver's licenses or personal identification cards, elected State officials, the Departments of Transportation and Homeland Security, and other interested parties. The purpose of this document is to invite interested parties to submit comments on the issues to be discussed and the interests and organizations to be considered for representation on the committee. DATES: You should submit your comments or applications for membership or nominations for membership on the negotiated rulemaking committee early enough to ensure that the Department's Docket Management System (DMS) receives them not later than March 25, 2005. Late-filed comments will be considered to the extent practicable. ADDRESSES: You should mention the docket number of this document in your comments or application/nomination for membership and submit them in writing to: Docket Management System (DMS), Room PL-401, 400 Seventh Street, SW., Washington, DC 20590. Commenters may also submit their comments electronically. Instructions for electronic submission may be found at the following Web address: http://dms.dot.gov/submit/. You may call the Docket at 202-366-9324, and visit it from 10 a.m. to 5 p.m., Monday through Friday. Interested persons may view docketed materials on the Internet at any time. Instructions for doing so are found at the end of this notice. You may read the comments received by DMS at the address given above under ADDRESSES. The hours of the Docket are indicated above in the same location. You may also review all documents in the docket via the internet. To read docket materials on the internet, take the following steps: 1. Go to the DMS Web page of the Department of Transportation (http://dms.dot.gov/). 2. On that page, click on ``search.'' 3. On the next page (http://dms.dot.gov/search/), type in the four- digit docket number shown at the beginning of this document. Example: If the docket number were OST-2005-1234,'' you would type ``1234.'' After typing the docket number, click on ``search.'' 4. On the next page, which contains docket summary information for the [[Page 8757]] docket you selected, click on the desired comments. You may download the comments. The comments are word searchable. Please note that even after the comment closing date, we will continue to file relevant information in the Docket as it becomes available. Further, some people may submit late comments. Accordingly, we recommend that you periodically check the Docket for new material. FOR FURTHER INFORMATION CONTACT: Robert C. Ashby, Deputy Assistant General Counsel for Regulation and Enforcement, Office of the General Counsel, at 202-366-9310 ([EMAIL PROTECTED]), or Steve Wood, Assistant Chief Counsel for Vehicle Safety Standards and Harmonization, Office of the Chief Counsel, National Highway Traffic Safety Administration, 202- 366-2992 ([EMAIL PROTECTED]) Their mailing addresses are at the Department of Transportation, 400 7th Street, SW., Washington, DC 20590, at rooms 10424 and 5219, respectively. SUPPLEMENTARY INFORMATION: I. Background On December 17, 2004, the President signed into law the Intelligence Reform and Terrorism Prevention Act of 2004. (Public Law No. 108-458). Title VII of that Act is known as the 9/11 Commission Implementation Act of 2004 (the
Re: [saag] Propping up SHA-1 (or MD5)
Nicolas Williams wrote: On Mon, Mar 21, 2005 at 11:56:44AM +, Ben Laurie wrote: It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) Eric proposed sending Random, Signature(H(Random || M)) and I then proposed sending Random || Signature(H(Random || M)) to avoid having to add a slot in existing protocols for Random. Another alternative: send Random-Key || Signature(HMAC(H(), Random-Key, M). However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). This proposal is specific to the use of hashes in signatures. Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. Yes. A third is that the length of the hash is changed, which could break existing protocols. Tie this to new algorithm OIDs and this problem goes away. You still have to figure out how to deploy new software. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) Note that this is not on-line. which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Yes. Now that we know that the attack is a differential cryptanalysis where the attacker has to control the first pair of blocks of the original message anything that makes it hard for the attacker to do this helps. H'(x) = H(H(x))) might do that trick, and on-line, but surely there's problems with that too (IANAC). This construction cannot solve the problem since H(x)=H(x') = H(H(x))=H(H(x')). Note that the attack implies that there exist weak messages, and Wang et. al. explicitly mention this in the paper on breaking MD4, and they mention the use of weak messages in second pre-image computation -- if a given message begins with a weak block pair then you can construct second pre-images. It'd be nice to know what the weak message distribution is for MD5 and SHA-1... Wouldn't it? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
Re: [saag] Re: Propping up SHA-1 (or MD5)
Ken Raeburn wrote: On Mar 22, 2005, at 11:51, Ben Laurie wrote: This can be fixed quite easily: H'(x)=H(H(x || H(x)) || H(x)) Doesn't this take us back to the original problem, by factoring in x only at the start of hash computations, so H'(x') will generate the same H(x') and the same internal state for H(x'||...) as for H(x||...) and thus the same H(x'||H(x')) etc, resulting in the same final value? Doh. Yes. Slightly less elegantly, then: H'(x)=H(H(x || H(0 || x) || H(0 || x)) Then you need two hashes running in parallel, but at least it is still online. Or, with three parallel streams: H'(x)=H(H(x || H(0 || x) || H(1 || x)) I don't feel as comfortable with either as the original construction, though. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
Re: [saag] Propping up SHA-1 (or MD5)
Nicolas Williams wrote: On Tue, Mar 22, 2005 at 05:31:44PM +, Ben Laurie wrote: Nicolas Williams wrote: Now that we know that the attack is a differential cryptanalysis where the attacker has to control the first pair of blocks of the original message anything that makes it hard for the attacker to do this helps. H'(x) = H(H(x))) might do that trick, and on-line, but surely there's problems with that too (IANAC). This construction cannot solve the problem since H(x)=H(x') = H(H(x))=H(H(x')). But it changes the attacker's problem. Currently the attacker has to find a first block of a weak message, then find the second block of the same, then he can generate collisions at will. The weak message generation requires some effort, and surely -- huge assumption here -- it takes more effort to find a weak message whose hash is also a weak message. The hash does not need to be weak, since the two hashes are the same, and so their hashes are also the same. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
Re: Encryption plugins for gaim
On 14/03/05 Adam Fields said: Given what may or may not be recent ToS changes to the AIM service, I've recently been looking into encryption plugins for gaim. If you use jabber, note that the Psi client supports 2-person PGP encrypted conversations. I sometimes find it useful. http://psi.affinix.com/ Mike -- Michael P. Soulier [EMAIL PROTECTED] http://www.digitaltorque.ca http://opag.ca python -c 'import this' Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature
What is to be said about pre-image resistance?
Collision resistance of message digests is effected by the birthday paradox, but that does not effect pre-image resistance. (correct?) So can we suggest that for pre-image resistance, the strength of the SHA-1 algorithm may have been reduced from 160 to 149? Or can we make some statement like reduced by some number of bits that may be related to 11? Or is there no statement we can make? iang PS: There is a nice description (with a bad title) here for the amateurs like myself: http://www.k2crypt.com/sha1.html -- News and views on what matters in finance+crypto: http://financialcryptography.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: NSA warned Bush it needed to monitor networks
... Obviously any bureaucrat with the authority to categorize something as secret will more or less automatically so stamp any information that passes through his hands, to inflate his importance, and thus his job security and prospects for promotion. I think a bigger issue here is a sort of rational (to the bureaucrat) risk aversity: if he declassifies something and it turns out he's leaked something valuable (in the eyes of his boss), he's in trouble. As long as there's no cost to stamping secret or FOUO on every document his office produces, this is safer for him than any other course of action. Along with this, going through a document to make sure there's nothing secret in there is a lot more work than just classifying it. The same logic works in the private world--how much of the stuff you've seen under NDA was genuinely going to cause a problem to the company that produced it, if someone just posted it to their website? ... This results in top secret information being treated as not very secret at all, as documented by Richard Feynman, which in turn results in ever higher secrecy classifications, more top than top, a process of classification inflation and debasement. I suspect something very similar happens with the watchlists. I wonder how many different layers of watchlist there are by now --digsig James A. Donald --John Kelsey - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Do You Need a Digital ID?
Jerrold Leichter wrote: That's fine for *describing* the system, and useful for analyzing its usability or acceptability. But it's not the whole story. 3-factor authentication paradigm obviously doesn't take into account whether the authentication material is treated as a secret or a shared-secret i.e. both biometrics and something you know can be implemented as either secret or shared-secret shared-secret tends to have copies of the authentication material in the possession of the relying party ... while secret tends to be an infrastructure where the relying-party can infer the existance of the secret by other characteristics. it is one of the reasons that the x9.84 biometric standard goes to great deal of description when biometrics are implemented as shared-secrets ... with the biometric templates stored at a central site. 3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct knowledge of the other party being in possession of the corresponding private key ... the relying party just infers it from the validation of a digital signature with the public key. which then takes us back to your original response: This is a rather bizarre way of defining things. Something you have is a physical object. On the one hand, any physical object can be copied to an arbitrary degree of precision; on the other hand, no two physical objects are *identical*. So a distinction based on whether a replacement is identical to the original gets you nowhere. ref: http://www.garlic.com/~lynn/aadsm19.htm#2 Do you Need a Digital ID? or http://www.mail-archive.com/cryptography%40metzdowd.com/msg03734.html 3-factor authentication paradigm obviously also doesn't cover all the sort of business rules that allow a relying party to infer something to be true ... even when they don't have direct evidence that it is true aka for a public/private key infrastructure where the relying party normally is inferring that the private key owner has in fact attempted to consistantly and reliably maintained the confidentiality and privacy of the private key and therefor its usefullness as part of any 3-factor authentication paradigm. 3-factor authentication paradigm might also help people designing and/or analysing authentication infrastructures. something you know operations may be some what more vulnerable to electronic sniffing, phishing, and/or information harvesting attacks. something you have hopefully are more resistant to electronic sniffing, phishing, and/or information harvesting attacks ... although the transmission of static data in non-face-to-face operations that allow the relying party to infer the possession of the something you have has been shown to be extremely vulnerable to skimming attacks (that enable the manufactor of counterfeit magstripe plastic cards). Obviously sniffing and skimming exploits involve very similar threat model. One application would be to choose a multi-factor authentication implementation where the different factors represent countermeasure to different threats. A multi-factor authentication implementation, where the different factors are vulnerable to the same threats, doesn't provide a great deal of additional security. However, there are obviously a lot of variouscharactistics like * face-to-face or non-face-to-face * direct evidence or inferring based on other evidence * static or non-static data * central store or remote inferrance * treat models * represents what kind of countermeasures * resistance to counterfeiting/impersonation * human factors a difficult human factors has been the issue of something you know shared-secrets. shared-secret pin/passwords have had two kinds of guidelines 1) make it hard to guess (which tends to make it difficult to memorize) 2) different shared-secret for every security domain (where most institutions viewed that they were the only security domain, but in reality many people now are faced with scores of different security domains with scores of extremely difficult to remember shared-secrets). lots of past posts on threats, vulnerabilities, exploits http://www.garlic.com/~lynn/subpubkey.html#fraud and lots of 3-factor authentication posts: http://www.garlic.com/~lynn/subpubkey.html#3factor and various past posts on general subject of designing high-assurance systems http://www.garlic.com/~lynn/subpubkey.html#assurance we have somewhat viewed assurance and high-availability as similar ... where a system needs to be resistant to all kinds of failures ... regardless of whether they were failures due to attacks/exploits or just plain simple
Re: Do You Need a Digital ID?
Anne Lynn Wheeler wrote: 3-factor authentication paradigm obviously also doesn't cover whether the authentication is direct fact-to-face or that the relying party is infering authentication taking place by the existance of other kinds of evidence. for instance, a relying party validating a digital signature with a public key will infer that the other party is in possession of the corresponding private key. the relying party may not have direct i.e. http://www.garlic.com/~lynn/aadsm19.htm#5 Do You Need a Digital ID? one of the possible side-effects of applying 3-factor authentication paradigm ... and observing that 1) the verification of a digital signature is just a method of inferring the possession of a specific private key 2) the possession of a private key obviously (theoritically possible, but i know of not instances of people memorizing private keys) isn't something you know authentication and a private key isn't something you are authentication ... leaving it to be something you have authentication (aka in your possession) 3) private keys in their simplest form are just electronic bits that are relatively easy to copy then in order for a private key to be useful in a something you have authentication, it follows fairly staight-forwardly that significant security procedures and countermeasures are required to prevent such copying (in order to provide some level of assurance that the assumed entity is consistantly and uniquely in possession of the specific private key). - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Propping up SHA-1 (or MD5)
All hash functions I'm aware of consist of an inner compression function that hashes a fixed size block of data into a smaller fixed size block and an outer composition function that applies the inner function iteratively to the variable length data to be hashed. Essentially you're proposing a modification to the outer layer of the hash construction. All of the standard hash functions since MD4 have been constructed so that a collision in the inner compression function is likely to lead to a collision in the hash function. MD2 did not have that property. It computed a cheap checksum of the variable length data in parallel with the digesting process and digested the checksum following the data. I have often wondered whether such a cheap addition would strengthen the newer hashes. (It would fix the suffixing attacks that motivated the development of HMAC). It's not obvious whether this would make the functions more secure or just make them harder to analyze. Perhaps someone from the research community could comment on why the checksum was removed in the evolution from MD2 to MD4. Your proposed encoding has the disadvantage that it would require two passes over the message being digested. This would be bad news for hardware implementations and should be avoided if possible. You note with the construction: H'(x)=Random || H(Random || x) (reminiscent of the salted hash calculation for UNIX passwords) that the hash gets longer. The hash need not get longer. If you have 40 random bits and the first 120 bits of H(Random || x), you match the size of SHA-1 and get improved security against most practical attacks. If your system depends on a fixed length hash, you're in trouble already because the fixed length is probably 128 bits and the world is headed toward 256. A problem that does exist with this construction is that some uses of hash functions assume that if you hash the same data you get the same hash (or indirectly, that if you sign the same data you get the same signature). In particular, you now need separate functions for generating a hash and for checking one. --Charlie Kaufman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ben Laurie Sent: Monday, March 21, 2005 3:57 AM To: Cryptography; [EMAIL PROTECTED] Subject: Propping up SHA-1 (or MD5) It was suggested at the SAAG meeting at the Minneapolis IETF that a way to deal with weakness in hash functions was to create a new hash function from the old like so: H'(x)=Random || H(Random || x) However, this allows an attacker to play with Random (the advice I've seen is that if one is going to use an IV with a hash function, then one should transfer the IV with integrity checks to deny attackers this freedom). Another objection is that this construction changes the API at the sender end, which could lead to a great deal of complexity when the use of the hash API is deeply embedded. A third is that the length of the hash is changed, which could break existing protocols. Musing on these points, I wondered about the construction: H'(x)=H(H(x) || H(H(x) || x)) which doesn't allow an attacker any choice, doesn't change APIs and doesn't change the length of the hash. Does this have any merit? Note that this is essentially an HMAC where the key is H(x). I omitted the padding because it seems to me that this actually makes HMAC weaker against the current attacks. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Propping up SHA-1 (or MD5)
Charlie Kaufman wrote: All hash functions I'm aware of consist of an inner compression function that hashes a fixed size block of data into a smaller fixed size block and an outer composition function that applies the inner function iteratively to the variable length data to be hashed. Essentially you're proposing a modification to the outer layer of the hash construction. All of the standard hash functions since MD4 have been constructed so that a collision in the inner compression function is likely to lead to a collision in the hash function. MD2 did not have that property. It computed a cheap checksum of the variable length data in parallel with the digesting process and digested the checksum following the data. I have often wondered whether such a cheap addition would strengthen the newer hashes. (It would fix the suffixing attacks that motivated the development of HMAC). It's not obvious whether this would make the functions more secure or just make them harder to analyze. Perhaps someone from the research community could comment on why the checksum was removed in the evolution from MD2 to MD4. Your proposed encoding has the disadvantage that it would require two passes over the message being digested. This would be bad news for hardware implementations and should be avoided if possible. I suggested in a later version these two constructions: H'(x)=H(H(x || H(0 || x) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x) || H(1 || x)) which only require a single pass (but, unfortunately, two or three different instances of the hash). This seems similar to the mechanism used in MD2, except the checksum is expensive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
REMINDER: CFP - ESORICS 2005: Deadline extension (April 1)
--- begin forwarded text From: Claudio Agostino Ardagna [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Thu, 24 Mar 2005 12:24:21 +0100 Subject: [p2p-hackers] REMINDER: CFP - ESORICS 2005: Deadline extension (April 1) Reply-To: Peer-to-peer development. [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] [Apologies if you receive multiple copies of this message] CALL FOR PAPERS ESORICS 2005 10TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Milan, Italy - September 14-16, 2005 http://esorics05.dti.unimi.it/http://esorics05.dti.unimi.it/ Due to several requests the deadline is extended to April 1, 2005 (firm) Papers offering novel research contributions in any aspect of computer security are solicited for submission to the Tenth European Symposium on Research in Computer Security (ESORICS 2005). Organized in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and has been held on alternate years in different European countries and attracts an international audience from both the academic and industrial communities. From 2002 it has been held yearly. The Symposium has established itself as one of the premiere, international gatherings on information assurance. Papers may present theory, technique, applications, or practical experience on topics including: - access control - accountability - anonymity - applied cryptography - authentication - covert channels - cryptographic protocols - cybercrime - data and application security - data integrity - denial of service attacks - dependability - digital right managament - firewalls - formal methods in security - identity management - inference control - information dissemination control - information flow control - information warfare - intellectual property protection - intrusion tolerance - language-based security - network security - non-interference - peer-to-peer security - privacy-enhancing technology - pseudonymity - secure electronic commerce - security administration - security as quality of service - security evaluation - security management - security models - security requirements engineering - security verification - smartcards - steganography - subliminal channels - survivability - system security - transaction management - trust models and trust management policies - trustworthy user devices The primary focus is on high-quality original unpublished research, case studies and implementation experiences. We encourage submissions of papers discussing industrial research and development. Proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series. INSTRUCTIONS FOR PAPER SUBMISSIONS Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font), and at most 20 pages total. Committee members are not required to read the appendices, and so the paper should be intelligible without them. To submit a paper, send to mailto:[EMAIL PROTECTED][EMAIL PROTECTED] a plain ASCII text email containing the title and abstract of your paper, the authors' names, email and postal addresses, phone and fax numbers, and identification of the contact author. To the same message, attach your submission (as a MIME attachment) in PDF or portable postscript format. Do NOT send files formatted for word processing packages (e.g., Microsoft Word or WordPerfect files). Submissions not meeting these guidelines risk rejection without consideration of their merits. Submissions must be received by March 25, 2005 in order to be considered. Notification of acceptance or rejection will be sent to authors by May 30, 2005. Authors of accepted papers must be prepared to sign a copyright statement and must guarantee that their paper will be presented at the conference. Authors of accepted papers must follow the Springer Information for Authors' guidelines for the preparation of the manuscript and use the templates provided there. GENERAL CHAIR Pierangela Samarati University of Milan email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] PROGRAM CHAIRS Sabrina De Capitani di Vimercati University of Milan email: mailto:[EMAIL PROTECTED][EMAIL PROTECTED] Paul Syverson Naval Research Laboratory url: http://www.syverson.orgwww.syverson.org PUBLICATION CHAIR Dieter Gollman TU
DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service
* DIMACS Workshop on Theft in E-Commerce: Content, Identity, and Service April 14 - 15, 2005 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Drew Dean, SRI International, [EMAIL PROTECTED] Markus Jakobsson, Indiana University, [EMAIL PROTECTED] Presented under the auspices of the Special Focus on Communication Security and Information Privacy and is sponsored by RSA Security. This workshop is focusing on Theft in E-Commerce (of content, identity and service). While theft is an old problem, the automated nature of e-commerce introduces new opportunities for traditional forms of theft, as well as entirely new forms of theft. The centrality of computation makes these threats a part of computer security. This is an area of research where we are seeing a lot of activity, and where we believe there is a great potential for valuable research contributions. While our primary interest is in defenses against theft, we are also interested in novel attacks and real data about attacks, as the defenders need to know what to defend against. It is our hope that we could stimulate such research by bringing together the leaders in this area, which is the very intention of this workshop. ** Workshop Program: This is a preliminary program subject to change. Thursday, April 14, 2005 8:00 - 8:30 Registration and Breakfast 8:30 - 8:45 Welcome and Opening Comments Fred Roberts, DIMACS Director 8:45 - 9:45 Identity Theft: A Risk to Be Managed Richard A Parry, Consumer Risk Management, JPMorganChase 9:45 - 10:15 Identity Theft and Legitimately - Minted Fraudulent Credentials Paul Van Oorschot, Carleton University, Canada 10:15 - 10:30 Break 10:30 - 11:15 Some are not thieves! Alexandr Andoni, MIT 11:00 - 11:30 Using Mutual Authentication to Fight Phishing Steve Myers, IUB 11:30 - 12:00 Building a Cryptovirus Using Microsoft's Cryptographic API Adam L: Young, LECG, LLC 12:00 - 1:30 Break 1:30 - 2:00 An open - source USB token Hein Roehrig, University of Calgary 2:00 - 2:30 Passwords Don't Get No Respect - - Or, How to Make the Most of (Weak) Shared Secrets Burt Kaliski, RSA Security 2:30 - 3:00 Blocking Phishing Spam: Pitfalls and Future Directions Minaxi Gupta, IUB 3:00 - 3:15 Break 3:15 - 3:45 Phishing Countermeasures Aaron Emigh, Radix Labs 3:45 - 4:15 Messin' with Texas: Deriving Mother's Maiden Names Using Public Records Virgil Griffith, IUB Friday, April 15, 2005 8:00 - 8:30 Breakfast and Registration 8:30 - 9:15 Identity Theft: Methods and Prevention John Black, University of Colorado 9:00 - 9:30 Preventing Theft in the Open Naftaly Minsky, Rutgers University 9:30 - 10:15 Expressing Human Trust in Distributed Systems: the Mismatch Between Tools and Reality Sean Smith, Dartmouth College 10:00 - 10:15 Break 10:15 - 10:45 Separable Identity - Based Ring Signatures: Theoretical Foundations for Fighting Phishing Attacks Susan Hohenberger, MIT 10:45 - 11:15 Fighting Phishing Attacks: A Lightweight Trust Architecture for Detecting Spoofed Emails Ben Adida, MIT 11:15 - 11:45 How to Search Privately on Streaming Data Rafail Ostrovsky, UCLA 11:45 - 12:15 Distributed Phishing Attacks Markus Jakobsson, IUB, CACR 12:15 - 1:45 Lunch 1:45 - 2:15 Are Peripheral Security Indicators Effective to Prevent Phishing Attacks? Min Wu, MIT 2:15 - 2:45 Kleptography: The Outsider Inside Your Crypto Devices, and its Trust Implications Moti Yung, Columbia University 2:45 - 3:15 Safeguarding wireless service access Panos Papadimitratos, Virginia Tech 3:15 - 3:30 Break 3:30 - 4:00 Social Networks and Trust Networks Jean Camp, IUB 4:00 - 4:30 Fraud and Fraud Reduction on the Internet Bezalel Gavish, Southern Methodist University ** Registration: Pre-registration deadline: April 7, 2005 Please see website for registration information http://dimacs.rutgers.edu/Workshops/Intellectual/ * Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Intellectual/ **PLEASE BE SURE TO PRE-REGISTER EARLY**
Re: [saag] Re: Propping up SHA-1 (or MD5)
Blumenthal, Uri wrote: Ernie Brickell suggested the following construct: H'(x) = H( H(x) || H(0 || x) ) Like him, I see no reason in going (H(x) || H(0||x) || ... || H(n||x)). Sorry, I got my parentheses wrong. I meant... H'(x)=H(H(x || H(0 || x)) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x)) || H(1 || x)) the former being almost the same construction as suggested, except that H(0 || x) is appended to the first inner hash. I used this construction because nested keyed hashes have provable security properties (which is why HMAC is made the way it is). The second form is the one required to get those properties, I should point out. I will confess that I have punted on whether those properties are actually useful. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
RE: Propping up SHA-1 (or MD5)
Whether these various tricks help depends on the technical details of the attacks found. I hope that the bit twiddling crypto types who are finding the attacks are going to propose something to fix them. There are probably cheaper fixes than the 2x or 3x performance loss of your algorithm down in the inner loops of these algorithms (such as the change from SHA to SHA-1) and that these will come out. I'm reluctant to jump on the SHA-256 bandwagon or to come up with some ad hoc fix until a more thorough analysis is done. SHA-256 was designed before these attacks were known and probably has related flaws (though they are even less likely to be practically exploitable). We have the luxury of having the current break being largely theoretical, so waiting even a year for the mathematicians is probably OK. But it's never too early to start preparing for a new algorithm - perhaps with a new hash size - in our protocols. Further, given that lots of attacks (past and present) are not exploitable if every hashed quantity includes some value chosen by a trusted party and unpredictable by an attacker, it seems reasonable to consider that as a desirable characteristic as we design our protocols. --Charlie Kaufman p.s. Your formulae below have unbalanced parentheses, but I can guess what you probably meant. -Original Message- From: Ben Laurie [mailto:[EMAIL PROTECTED] Sent: Thursday, March 24, 2005 2:39 AM To: Charlie Kaufman Cc: Cryptography; [EMAIL PROTECTED] Subject: Re: Propping up SHA-1 (or MD5) Charlie Kaufman wrote: All hash functions I'm aware of consist of an inner compression function that hashes a fixed size block of data into a smaller fixed size block and an outer composition function that applies the inner function iteratively to the variable length data to be hashed. Essentially you're proposing a modification to the outer layer of the hash construction. All of the standard hash functions since MD4 have been constructed so that a collision in the inner compression function is likely to lead to a collision in the hash function. MD2 did not have that property. It computed a cheap checksum of the variable length data in parallel with the digesting process and digested the checksum following the data. I have often wondered whether such a cheap addition would strengthen the newer hashes. (It would fix the suffixing attacks that motivated the development of HMAC). It's not obvious whether this would make the functions more secure or just make them harder to analyze. Perhaps someone from the research community could comment on why the checksum was removed in the evolution from MD2 to MD4. Your proposed encoding has the disadvantage that it would require two passes over the message being digested. This would be bad news for hardware implementations and should be avoided if possible. I suggested in a later version these two constructions: H'(x)=H(H(x || H(0 || x) || H(0 || x)) or: H'(x)=H(H(x || H(0 || x) || H(1 || x)) which only require a single pass (but, unfortunately, two or three different instances of the hash). This seems similar to the mechanism used in MD2, except the checksum is expensive. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ 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]
Petname Tool version 0.5
Tyler Close has written an anti-phishing tool for the Firefox browser called the Petname tool. It works with SSL sites, including those with self-signed certificates, and is available at http://www.waterken.com/user/PetnameTool/. Mark Stiegler has written an overview of petname systems, including a list of existing examples, available at: http://www.skyhunter.com/marcs/petnames/IntroPetNames.html. Note that Amir Herzberg and Ahmad Gbara's Trustbar system is an example of a pet name system. From the Petname Tool web site, Need help avoiding phishing and spoofing attacks? The petname tool can help you keep it all straight by clearly distinguishing your online relationships. Using the petname tool, you can save a reminder note about a relationship you have with a site. The petname tool will then automatically display this reminder note every time you visit the site. After following a hyperlink, you need only check that the expected reminder note is being displayed. If so, you can be sure you are using the same site you have in the past. Cheers - Bill - Bill Frantz| The first thing you need | Periwinkle (408)356-8506 | when using a perimeter | 16345 Englewood Ave www.pwpconsult.com | defense is a perimeter.| Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Banks and Online Retailers Lose Customers to the Fear of ID Theft
http://online.wsj.com/article_print/0,,SB63038793988394,00.html The Wall Street Journal March 24, 2005 PERSONAL JOURNAL Banks and Online Retailers Lose Customers to the Fear of ID Theft By KATHY CHU DOW JONES NEWSWIRES March 24, 2005; Page D2 Banks and online retailers are losing customers who fear they will become victims of identity theft, according to a new study. The study, conducted by Financial Insights, of Framingham, Mass., said that nearly 6% of consumers have changed banks and about 18% have stopped shopping online due to concerns that their personal information will be stolen. This means that, overall, about 12 million U.S. consumers have likely switched banks and 39 million have ceased online shopping, according to Financial Insights. The results come in the wake of high-profile database breaches where consumer information was lost or stolen. The survey was actually conducted before these incidents occurred, so it's likely that banks are at risk of losing even more customers now, according to Sophie Louvel, a Financial Insights analyst. It's not just the banks that have experienced data compromises that need to worry. Consumers may also leave if they perceive that banks don't have adequate security systems or if data breaches have occurred at partner institutions, according to the research firm. This clearly shows that customers are taking action, said Ms. Louvel, who has written an identity-theft report based on the data. I think the fundamental issue is that some customers don't have confidence in their bank's ability to protect them. Separate research conducted last year by Unisys Corp. revealed that nearly half of consumers would be willing to switch their accounts to financial institutions they perceived as having stronger theft detection and alert services. To the extent that consumers think of their personal information as property and assets, banks need to think this way, too, said Frank Liddy, a partner at Unisys in Blue Bell, Pa. John Hall, a spokesman at the American Bankers Association, said banks take the threat of security breaches very seriously. Institutions already have tough security standards in place for online banking and debit-card usage and will continue doing everything they can to prevent identity theft, Mr. Hall said. -- - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA ... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience. -- Edward Gibbon, 'Decline and Fall of the Roman Empire' - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Off-list request
I don't know if it's inappropriate to ask on this list, but regarding http://www.securescience.net/ciphers/csc2/ Can I get off-list quotes regarding a formal professional review and possible assistance in the steps taken to establish this cipher into the review process. Thank you. -- Best Regards, Lance James Secure Science Corporation [Have Phishers stolen your customers' logins? Find out with DIA] https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Propping up SHA-1 (or MD5)
Ben, I believe the fatal flaw here is not the crypto, but losing the ability to hash a stream without keeping all of it. Both the hashes and HMAC have this sometimes-vital property. This can be fixed quite easily: H'(x)=H(H(x || H(x)) || H(x)) I think this construction doesn't provide any additional security. If someone manages to find x1 and x2 such that H(x1)=H(x2), he will have also broken H'(X). If you get h=H(x1)=H(x2) (of course we are talking about hash functions using the same iterative model as SHA-1), then you would end calculating H(H(x1 || h) || h) vs H(H(x2 || h) || h), but since both x1 and x2 leave the internal state of the hash function the same, H(x1 || h) = H(x2 || h) and hence H'(x1) = H'(x2) Cheers, Pablo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
Really? How does one go about proving the security of a block cipher? My understanding is that you, and others, perform attacks against it, and see how it holds up. Many of the very best minds out there attacked AES, so for your new CS2 cipher to be provably just as secure as AES-128, all those people would have had to have spent as much time and energy as they did on AES. That strikes me as unlikely, there's a lot more interest in hash functions today. Adam PS: I've added the cryptography mail list to this. Some of the folks over there may be interested in your claims. On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote: | Secure Science is offering a preview of one of the 3 ciphers they will | be publishing througout the year. The CS2-128 cipher is a 128-bit block | cipher with a 128 bit key. This cipher is proposed as an alternative | hardware-based cipher to AES, being that it is more efficient in | hardware, simpler to implement, and provably just as secure as AES-128. | | http://www.securescience.net/ciphers/csc2/ | | -- | Best Regards, | Secure Science Corporation | [Have Phishers stolen your customers' logins? Find out with DIA] | https://slam.securescience.com/signup.cgi - it's free! | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
Adam Shostack wrote: Really? How does one go about proving the security of a block cipher? My understanding is that you, and others, perform attacks against it, and see how it holds up. Many of the very best minds out there attacked AES, so for your new CS2 cipher to be provably just as secure as AES-128, all those people would have had to have spent as much time and energy as they did on AES. That strikes me as unlikely, there's a lot more interest in hash functions today. We will be proposing 2 hashes as well. Adam PS: I've added the cryptography mail list to this. Some of the folks over there may be interested in your claims. On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote: | Secure Science is offering a preview of one of the 3 ciphers they will | be publishing througout the year. The CS2-128 cipher is a 128-bit block | cipher with a 128 bit key. This cipher is proposed as an alternative | hardware-based cipher to AES, being that it is more efficient in | hardware, simpler to implement, and provably just as secure as AES-128. | | http://www.securescience.net/ciphers/csc2/ | | -- | Best Regards, | Secure Science Corporation | [Have Phishers stolen your customers' logins? Find out with DIA] | https://slam.securescience.com/signup.cgi - it's free! | -- Best Regards, Lance James Secure Science Corporation [Have Phishers stolen your customers' logins? Find out with DIA] https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Information Incognito
http://online.wsj.com/article_print/0,,SB45546123985866,00.html The Wall Street Journal March 22, 2005 MEDIA MARKETING Information Incognito In War on Terror, U.S. Tries To Make Public Data Secret; The Almanac Under Wraps? By ROBERT BLOCK Staff Reporter of THE WALL STREET JOURNAL March 22, 2005; Page B1 Ever since Sept. 11, 2001, the federal government has advised airplane pilots against flying near 100 nuclear power plants around the country or they will be forced down by fighter jets. But pilots say there's a hitch in the instructions: aviation security officials refuse to disclose the precise location of the plants because they consider that SSI -- Sensitive Security Information. The message is; 'please don't fly there, but we can't tell you where there is,' says Melissa Rudinger of the Aircraft Owners and Pilots Association, a trade group representing 60% of American pilots. Determined to find a way out of the Catch-22, the pilots' group sat down with a commercial mapping company, and in a matter of days plotted the exact geographical locations of the plants from data found on the Internet and in libraries. It made the information available to its 400,000 members on its Web site -- until officials from the Transportation Security Administration asked them to take the information down. Their concern was that [terrorists] mining the Internet could use it, Ms. Rudinger says. The pilots' experience underscores one of the great policy clashes of the early 21st century: the War on Terror vs. the Information Age. In the 312 years since al Qaeda operatives studied commercial airlines schedules in preparation for flying jetliners into the World Trade Center and the Pentagon, the Bush administration has moved aggressively to keep once-easily accessible data under wraps. Some of that information could well be of use to would-be terrorists, but keeping other information secret strikes some observers as absurd. For example, when a top Federal Aviation Administration official testified last year before the 9/11 commission, his remarks were broadcast live nationally. But when the administration included a transcript in a recent report on threats to commercial airliners, the testimony was heavily edited. How do you redact something that is part of the public record? asked Rep. Carolyn Maloney, (D., N.Y.) at a recent hearing on the problems of government overclassification. Among the specific words blacked out were the seemingly innocuous phrase: we are hearing this, this, this, this and this. Government officials could not explain why the words were withheld, other than to note that they were designated SSI. The concept of Sensitive Security Information originated in a 1974 statute, which kept things like airport security plans out of public view. But the Homeland Security Act of 2002 greatly expanded the scope of SSI to include any data that could help someone defeat transportation security systems, including records of security inspections, work schedules, training materials and the regulations authorizing screeners to poke around in carry-on baggage. SSI is actually one of some 60 categories of SBU, or Sensitive But Unclassified information, a designation reserved for information that isn't top-secret, but which the government still doesn't want released publicly. Other pseudo-classifications, as they're called by Congress and some experts, include FOUO (For Official Use Only) and UCNI (Unclassified Controlled Nuclear Information). Every government agency has the ability to create its own form of SBU and any official can declare something sensitive. Under such labels, officials have ordered a wide range of information removed from public libraries and Web sites. Critics say there are signs that these designations are now being overused. One internal memo to Federal Air Marshals in Las Vegas last year stamped FOUO announced a farewell breakfast party for a colleague and invited co-workers for doughnuts and coffee. So has the Pentagon's city-size phone directory, which was once on sale at the U.S. government printing office, and is no longer offered to the public. It contains information about the specific locations of DoD officials, and other personnel, within the Pentagon, says spokesman Lt. Col. Gary L. Keck. Many officials involved in the new secrecy effort say such measures are vital to national security -- and that just because information has appeared in the public domain, doesn't mean it should be made more readily available. We don't want to disclose vulnerabilities of the nation to our adversaries, says Jack Johnson Jr., the former chief security officer for the Department of Homeland Security, who until last month oversaw the process of deciding what information was suitable for public consumption and what was too risky to let out. Some of the information that Mr. Johnson has deemed worthy of lock down included the fact that Casio brand wrist watches are popular with al
Re: Secure Science issues preview of their upcoming block cipher
| Really? How does one go about proving the security of a block cipher? They don't claim that: This cipher is ... provably just as secure as AES-128. I can come up with a cipher provably just as secure as AES-128 very quickly (Actually, based on the paper a while back on many alternative ways to formulate AES - it had a catchy title something like How Many Ways Can You Spell AES?, except that I can't find one like that now - one could even come up with a formulation that is (a) probably as secure as AES-128; (b) actually faster in hardware or simpler to implement or whatever...) -- Jerry :-) | My understanding is that you, and others, perform attacks against it, | and see how it holds up. Many of the very best minds out there | attacked AES, so for your new CS2 cipher to be provably just as | secure as AES-128, all those people would have had to have spent as | much time and energy as they did on AES. That strikes me as unlikely, | there's a lot more interest in hash functions today. | | Adam | | PS: I've added the cryptography mail list to this. Some of the folks | over there may be interested in your claims. | | On Wed, Mar 23, 2005 at 05:00:25PM -0800, BugTraq wrote: | | Secure Science is offering a preview of one of the 3 ciphers they will | | be publishing througout the year. The CS2-128 cipher is a 128-bit block | | cipher with a 128 bit key. This cipher is proposed as an alternative | | hardware-based cipher to AES, being that it is more efficient in | | hardware, simpler to implement, and provably just as secure as AES-128. | | | | http://www.securescience.net/ciphers/csc2/ | | | | -- | | Best Regards, | | Secure Science Corporation | | [Have Phishers stolen your customers' logins? Find out with DIA] | | https://slam.securescience.com/signup.cgi - it's free! | | | | - | The Cryptography Mailing List | Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] | - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
What is to be said about pre-image resistance?
Ian G writes: Collision resistance of message digests is effected by the birthday paradox, but that does not effect pre-image resistance. (correct?) So can we suggest that for pre-image resistance, the strength of the SHA-1 algorithm may have been reduced from 160 to 149? Well, I'm not sure that the difference between 2^160 and 2^149 would be very significant in practice, even if there were some redunction like this, but-- As far as I can tell, the pre-image resistance of SHA1 has not been significantly threatened by these attacks, or at least, the authors do not claim any results on pre-image resistance of SHA1. http://www1.ietf.org/mail-archive/web/cfrg/current/msg00790.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Secure Science issues preview of their upcoming block cipher
Jerrold Leichter writes: They don't claim that: This cipher is ... provably just as secure as AES-128. I can come up with a cipher provably just as secure as AES-128 very quickly Actually, I think Adam is totally right. Have you looked at their scheme? http://www.securescience.net/ciphers/csc2/ The way to come up with a cipher provably as secure as AES-128 is to use AES-128 as part of your cipher -- but their scheme does not do anything like that. I am very skeptical about claims that they have a mathematical proof that CS2-128 is as secure as AES-128. I want to see the proof. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
| Jerrold Leichter writes: | They don't claim that: | | This cipher is ... provably just as secure as AES-128. | | I can come up with a cipher provably just as secure as AES-128 very quickly | | Actually, I think Adam is totally right. | | Have you looked at their scheme? | http://www.securescience.net/ciphers/csc2/ I was responding in jest to the text Adam actually quoted - and indeed was refering to: | The way to come up with a cipher provably as secure as AES-128 is to use | AES-128 as part of your cipher [Remind self once more: Ironic humor doesn't work in mail] |-- but their scheme does not do anything | like that. | | I am very skeptical about claims that they have a mathematical proof that | CS2-128 is as secure as AES-128. I want to see the proof. I didn't see that claim on their site, but then again I only glanced at it quickly. Unless they have some entirely new kind of reduction, I'm guessing that what they are really claiming is that the same proofs of security that are available for AES - against generalized differential attacks, for example - are also available for CSC2. *That* much is certainly possible. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Secure Science issues preview of their upcoming block cipher
Jerrold Leichter wrote: I can come up with a cipher provably just as secure as AES-128 very quickly (Actually, based on the paper a while back on many alternative ways to formulate AES - it had a catchy title something like How Many Ways Can You Spell AES?, except that I can't find one like that now - one could even come up with a formulation that is (a) probably as secure as AES-128; (b) actually faster in hardware or simpler to implement or whatever...) You're probably looking for [1] by Barkan and Biham. What they do is replacing the irreducible polynomial and all the constants involved in Rijndael to get what they call dual ciphers; basically those ciphers are isomorphic to Rijndael. All in all they get 240 dual ciphers which are listed in [2]. What I found more interesting back then was that they also give square dual and log dual ciphers of Rijndael. I.e. let E be the Rijndael encryption and E' be the encryption function of the square/log dual Rijndael construction. Furthermore let f be a function that either performs bytewise squaring in GF(2^8) or replaces each byte with a logarithmic representation (relative to a generator g. you also need to fix log_g(0) = -\infty for this to make sense). Then E'(f(plaintext), f(key)) = f(E(plaintext, key)) holds. The squaring construction then also naturally extends to what they call higher-order self dual ciphers: meaning you can apply the squaring multiple times. In 2004 Wu, Lu and Laih then demonstrated that using Barkan's and Biham's method can indeed lead to more efficient implementations of AES/Rijndael in hardware. Cheers, Ralf [1] Elad Barkan and Eli Biham: In How Many Ways Can You Write Rijndael? ASIACRYPT 2002, Springer note: also on ePrint as http://eprint.iacr.org/2002/157 if you don't have Springer Link access [2] Elad Barkan and Eli Biham: The Book of Rijndaels http://eprint.iacr.org/2002/158 [3] Shee-Yau Wu and Shih-Chuan Lu and Chi Sung Laih: Design of AES Based on Dual Cipher and Composite Field Topics in Cryptology, CT-RSA 2004, Springer -- Ralf-P. Weinmann [EMAIL PROTECTED] TU Darmstadt, FB Informatik, FG Theoretische Informatik Tel: +49-(0)6151-16-6628 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: and constrained subordinate CA costs?
* Adam Back: Does anyone have info on the cost of sub-ordinate CA cert with a name space constraint (limited to issue certs on domains which are sub-domains of a your choice... ie only valid to issue certs on sub-domains of foo.com). Is there a technical option to enforce such a policy on subordinated CAs? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: What is to be said about pre-image resistance?
Ian, The Wang attack does nothing (yet) for second preimages. The best attack I know of against them refers is in Kelsey and Schneier's *Second Preimages on n-bit Hash Functions for Much Less than 2^n Work.* It's at: http://eprint.iacr.org/2004/304 Once you cut through the verbiage, it's really pretty simple: The bigger a file, the more intermediate hashes there are inside of it. The more intermediate hashes, the more points there are to collide against. So, a 700MB CD image vs. a hash with a 512 bit blocksize will have 734,003,200 bytes / 64 bytes = 11,468,800 intermediate hashes that may be collided against. That's a little more than 2^23. Against MD5, you're looking at 2^105 for a CD; against SHA-1, you're looking at 2^137. This is of course work that's far outside the range of feasibility (and, in a small ahem to the paper, 2^60 byte messages are equally ridiculous). You may say this isn't a true second preimage attack, because you only acquire an intermediate collision. But all intermediate collisions can be appended to with legitimate data until they return to the correct final hash state. So you generate your malicious data, search for random garbage that, when appended, equals one of the 11M potential states, and then append the rest of the legitimate file from that point. MD Hardening, i.e. the conclusion of a data stream with its own length, *does* create a problem though. We cannot alter the final length of the file, or the hash will fail. So if we find an intermediate collision at an earlier point in the file than our malicious payload requires, we must discard it. For large malicious payloads (say, replacing one CD entirely with another), this eliminates our attack window entirely. Of course, again, 2^105 work is ridiculous. --Dan Ian G wrote: Collision resistance of message digests is effected by the birthday paradox, but that does not effect pre-image resistance. (correct?) So can we suggest that for pre-image resistance, the strength of the SHA-1 algorithm may have been reduced from 160 to 149? Or can we make some statement like reduced by some number of bits that may be related to 11? Or is there no statement we can make? iang PS: There is a nice description (with a bad title) here for the amateurs like myself: http://www.k2crypt.com/sha1.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
