AES and Intellectual Property issues
I just got this message from NIST's Edward Roback. There seems to be a possibility that the AES contest could be endangered by claims of intellectual property rights on competing algorithms. Unfortunately some of the stronger candidates seem to be the less enlightened ones in this matter. It is a pity that NIST did not ask for a clear statement to that effect before accepting the candidates. I suppose there is still time to apply some pressure before announcing the algorithms that will make it to the second round. Date: Thu, 04 Mar 1999 16:09:23 -0500 To: From: Edward Roback Subject: draft Int. property slides AES Submitters, You may recall that last year we posed a question to you (on an infomral, non-binding basis) regarding intellectual property. There has been interest in providing a summary of what we found at the upcoming AES #2 conference on March 22-23 during NIST's briefings to the conference. I wanted to give each of you a chance to see our draft summary and characterization of your responses. Feel free to send me any comments you may have. Thanks! Ed Roback, NIST draft slide 1: Intellectual Property (IP) Questions have been raised with NIST regarding the possibility that submitters may claim that their IP is infringed by the practice of another candidate algorithm. So, in the spirit of trying to obtain a worldwide royalty-free algorithm, NIST posed the following question to the 15 submitters (for informal, non-binding response): Are you willing to waive any IP rights you may have on any party who makes, uses, or sells implementations of the selected AES algorithm(s) (no matter which algorithm is selected) ? draft slide 2: Summary of Responses Unqualified Yes: CAST-256, Crypton, DEAL, Frog, LOKI97, Rijndael, Serpent, Twofish Yes, clarified:Safer+ Yes, if: HPC Not quite Yes: E2, MARS, No:RC6 Cant say: DFC No response: Magenta Original text ends here Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
Re: Strengthening the Passphrase Model
On Wednesday, February 10, 1999 16:17:48 -0500 (EST) you wrote: >I think the best thing would be to display about 10 - 20 random diceware >words and let the user construct a phrase out of them that (s)he finds >reasonably easy to recall. > >For instance: dwarf nutmeg ale delta cb tans riot saint polka > >"nutty meg and the saint caused a dwarf polka riot" > >This has at least 64 bits of entropy, and probably a lot more (but the >rest is hard to measure). Or even, "... the saint of ale " I expound a similar idea (with tables for computing the resulting entropy, etc)in www.tecapro.com/makepass.htm Here you will find a free pass phrase constructor program as well as a free list of common and short English words. Our list is shorter (4096 words) than diceware's but its words are more common and easier to remember. Recently we have been developing a personal key manager (it uses 3 key 3DES, Blowfish and GodSave - an "overkill" style cipher developed by us). What is nice about this product is that it integrates seamlessly with any Windows application asking for a password. Please send me an email if you would like to get a beta to play with. >> 3. PGP should be available on a bootable CD-ROM for the major platforms. > >As others have pointed out, no one would reboot to use PGP. 'Nuff said. It would be nice to have the option though. The bootable CD-ROM should include an email-client that does not use any of the hard disk based OS, correct? Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
Re: Draft FIPS 46-3 Up
This FIPS defines 3DES en EDE mode with three different DES keys. Apart from the fact that when used with identical keys the EDE mode works as single DES, is there any advantage of this mode compared to the more "natural" EEE mode? On Wednesday, January 20, 1999 15:52:23 -0500 you wrote: > >Jim Foti at NIST has put the Draft FIPS 46-3 at: > > http://csrc.nist.gov/fips/dfips46-3.pdf (209K) > >We offer an HTML version: > > http://jya.com/dfips46-3.htm (49K + 35K images) > Original text ends here ---- Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
RE: Is a serial cable as good as thin air?
Thank you all for the feedback; I will take your observations into account - replay attacks are accounted for and, for good measure, I will include a random delay to invalidate timing attacks. I see now that I should have been somehow more specific with my original question: Our home banking applications let the client use public Internet to access information about his accounts and allow for limited off-line transactional capability, such us to debit this account to pay that credit card. Encryption and decryption are implemented on the client's computer and within the bank's network. The Internet server is used only as a encrypted data repository and as a communications link. Now we want to implement on-line transactional capability. Here I am not concerned about the security of our application itself, but rather whether our application can be used to attack the bank's private computer network and interfere with the bank's normal operation. On this network we plan to install a PC connected to the Internet server by a serial cable. A dedicated program on this PC will receive from the Internet server encrypted data packages. These packages will be decrypted with the individual clients' passwords, the resulting plaintext will be validated, and if all looks right it will be forwarded and processed by the bank's internal system. All packages that do not validate correctly will be discarded. If three or so packages with the same client id fail to validate in a row, future packages with this id will be processed slowly. Now, my reasoning is this: as I understand it, when a hacker attacks a network, he finds a way to access or modify files on this network, execute system level commands or plant his own code. As far as I can see this will be impossible in our set-up; an attacker will never be able to do anything worse than fake transactions of our own application and therefore the bank's risk cannot be higher than that. The serial connection will not be one-way. The networked PC will use the same cable to send (encrypted) confirmations to the clients and to update the (encrypted) data base on the Internet Server. If the internal network itself cannot be compromised, neither is there any danger in having data sent out by our own program. Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
Is a serial cable as good as thin air?
We are installing home banking systems where the Internet Server is separated from the bank's computer center by air. Data is moved periodically back and forth using low tech but dependable floppy disks that carry only encrypted data (the principle of red/black separation is implemented by loading only encrypted data on the server). This "air-wall" is an effective way to stop hackers from penetrating the bank's computer center using its Internet services. This works quite well with services such as users' credit-card queries. Now, we have a potential client insisting on on-line transaction capability. One possible solution is to connect the Internet server with a PC on the bank's private network using a serial cable. We would write our own transmission protocol. The PC working on the bank's network would run a memory resident program that services the serial port and will discard any blocks that do not decrypt properly or have an invalid structure (only blocks that decrypt into the correct data structure would be processed at all). Here is the question: Is this as good as thin air? Can you see any way a hacker could use such a connection to penetrate the bank's network? Dianelos Georgoudis email: [EMAIL PROTECTED] http://www.tecapro.com
