No Subject
Hi... I need help. I am a student studying crypto protocols (newbies). I have a problem pertaining group signatures, which has many use in electronic commerce too. My problem ~~~ Actually, right now, I want to create a group signature, which upon group signature verification by the group manager, the 'private signing key' of the signer will remain hidden. Of course, the group manager will still know who sign the signature by recovering proofs/traces of signer's public 'key' or public 'identity' in the signature. If this can be accomplished, it means that the signer can use the same 'private signing key' for an unlimited number of times, even if his identity is revealed upon signature opening by the group manager (but only his public 'identity' / 'key'). Related paper: ~~~ I've studied a paper titled "Efficient Group Signature Scheme for Large Group" (Crypto 97) by Jan L. Camenisch and Markus Stadler. Their solution is nice and really efficient. However, I think, in the paper, the group manager can impersonate the member, after the group manager opens a group signature. The reason is because the signer's 'private signing key is compromised' by the group manager. Is this true? I do not want this property. If anyone can give me some directions what should I have to do (to let the group manager know only the public 'identity' of the signer upon signature opening), I really appreciate it. Or, if somebody you know has already published the solution to this problem (at least as efficient as your basic group signature protocol), please let me know. Thank you very much. Sincerely -mukti
No Subject
Now here's an interesting question that no one has so far addressed: What happens if you happen to come home early and catch these guys in the act? They can't reveal their methods; so do you just "disappear"? Think about it: (1) they've already decided you are guilty of something, and are just looking for proof, (2) they're armed, (3) they're on hair-trigger alert because they've broken into your home, and finally (4) now there is a witness to their techniques... So maybe you just have a nasty encounter with "burglars" and are shot and killed, they conceal all evidence that they were ever in your house, and your unfortunate murder is never solved.
Re: Subject: Re: Security Lab To Certify Banking Applications (was Re: ECARM NEWS for July 23,1999 Second Ed.)
Keeping an ITSEC TOE confidential is not unusual. It would be more unusual to not keep it confidential or at least restricted distribution, given the contents. It is a major flaw of the scheme...you are trusting the certifier to enforce a "good" TOE if they are going to give an E3-High rating. In the ITSEC scheme, saying something is certified as "E3" says nothing substantial anyway. (E levels refer to correctness of implementation, which is quite important, but not the whole story.) You also need to know the rating for the "strength of mechanism", which is Basic, Medium or High. In other workds there's another work-around that is at least as simple as what you stated: 1. Define your TOE as tough or easy as you like. 2. Do a reasonably good job of documenting your process and doing configuration management. Don't worry about how secure your product is. 3. Do the certification process, pay the $$. Get an E3-Basic (lowest level) rating from the certifier. 4. Tell your customers that you "passed ITSEC E3", but don't tell them at what strength. Rely on their ignorance to not ask the most important question. - ml Peter Gutmann wrote: Actually there's a way you can manage this (which was used by MS to get NT's ITSEC E3 certification in the UK): 1. Define your own TOE (target of evaluation) for the certification (translation: lower your expectations to the point where they're already met). 2. Have the product certified to your own TOE. 3. Mark the TOE "Microsoft Confidential" and don't let anyone see it (leading to considerable speculation about how you could possibly manage to write a TOE which would allow NT to get an E3 certification). 4. Tell everyone you have an E3 certified OS and sell it to government departments as secure. This isn't to say that the certification process is a bad thing. If it's done properly it can lead to a reasonable degree of assurance that you really do have a secure product, which is exactly what was intended. Unfortunately if all you're interested in is filling a marketing checkbox, you can do this as well. This was the Orange Book's strength (and weakness), it told you exactly what you had to do to get the certification so you couldn't work around it with fancy footwork. OTOH it was also inflexible and had requirements which didn't make sense in many instances, which is what lead to the development of alternatives like ITSEC/the Common Criteria. For all its failings I prefer the Orange Book (if it can be made to apply to the product in question) because that way at least you know what you're getting. (Given that NT now has a UK E3 certification, I don't think you need to get it recertified in the US, since it's transferrable to all participating contries, so I don't think it'd have to be certified by the above lab). Peter.
No Subject
On Sun, 25 Jul 1999, John Kelsey wrote: Has anyone looked at this from a cryptanalytic point of view? I think there are chosen-input attacks available if you do this in the straightforward way. That is, if I get control over some of your inputs, I may be able to alternate looking at your outputs and sending in new inputs, and mount an attack that isn't possible at all against RC4 as it's normally used. (This comes out of conversations with Jon Callas, Dave Wagner, and Niels Ferguson, from a time when I considered designing a Yarrow-variant using RC4 as the underlying engine.) Even aside from active attacks, there is a possible problem based on the fact that RC4 can "almost" fall into a repeated-state situation. RC4's basic iteration looks like: (1) i += 1; (2) j += s[i]; (3) swap (s[i], s[j]); (4) output s[s[i] + s[j]]; (everything is mod 256) The danger is that if it ever gets into the state j = i+1, s[j] = 1, then it will stay that way. It will increment i, then add s[i] to j, which will also increment j. Then which it swaps s[i] and s[j] it will make s[j] be 1 again. However in normal use this never happens, because this condition propagates backwards as well as forwards; if we ever are in this state, we always were in this state. And since we don't start that way, we never get that way. Adding input entropy could break these rules. If we fold in entropy following the pattern of RC4 seeding, we alter line 2: (2) j += s[i] + input(); Now it is no longer true that we can't fall into (or out of) this state. If we had a non-zero input() value and then a bunch of zeros, we could get into the repeated state and stay there. It may not be that easy to recognize the repeated state, but it certainly makes the RNG seem less robust. The effect is that the "1" value keeps bubbling through the s array, with every other value moving up one step as the "1" value moves past it. The s array ends up rotating very slowly, not being mixed at all. This is completely unlike normal RC4. It is really not safe to mess with RC4's iteration rules like this. The cipher is rather brittle in this regard.
Subject: Re: Security Lab To Certify Banking Applications (was Re: ECARM NEWS for July 23,1999 Second Ed.)
"William H. Geiger III" [EMAIL PROTECTED] writes: In v0421012db3be70faae9c@[207.244.108.87], on 07/23/99 at 03:20 PM, Robert Hettinga [EMAIL PROTECTED] said: The Financial Services Security Laboratory will open July 28 in Reston, Va. The facility will be used to test software packages against a set of standards for securing e-commerce and bill-payment applications, as well as browsers and operating software. Well I have my doubts on this. Either they refuse to certify Microsoft Netscape software and alienate 90% of the consumer market, or they do certify them making their certification worthless. Actually there's a way you can manage this (which was used by MS to get NT's ITSEC E3 certification in the UK): 1. Define your own TOE (target of evaluation) for the certification (translation: lower your expectations to the point where they're already met). 2. Have the product certified to your own TOE. 3. Mark the TOE "Microsoft Confidential" and don't let anyone see it (leading to considerable speculation about how you could possibly manage to write a TOE which would allow NT to get an E3 certification). 4. Tell everyone you have an E3 certified OS and sell it to government departments as secure. This isn't to say that the certification process is a bad thing. If it's done properly it can lead to a reasonable degree of assurance that you really do have a secure product, which is exactly what was intended. Unfortunately if all you're interested in is filling a marketing checkbox, you can do this as well. This was the Orange Book's strength (and weakness), it told you exactly what you had to do to get the certification so you couldn't work around it with fancy footwork. OTOH it was also inflexible and had requirements which didn't make sense in many instances, which is what lead to the development of alternatives like ITSEC/the Common Criteria. For all its failings I prefer the Orange Book (if it can be made to apply to the product in question) because that way at least you know what you're getting. (Given that NT now has a UK E3 certification, I don't think you need to get it recertified in the US, since it's transferrable to all participating contries, so I don't think it'd have to be certified by the above lab). Peter.
No Subject
At 08:09 PM 7/7/99 -0500, William H. Geiger III wrote: Well it's only DES which we all know can easily be broken. Doing weak crypto really fast is not all that impressive to me. That's because you're trying to write, not read. Get it? Les Fedz
No Subject
[This just arrived in the list inbox. I'm not exactly sure that it is particularly interesting, accurate or informative, but unfortunately because it arrived anonymously I'm not really in a position to ask for an improved version. Anyway, I decided to forward it. --Perry] -- Forwarded message -- Subject: Crypto Equipment Guide -- Part One of Two Date: Mon, 17 May 1999 16:01:59 -0500 CRYPTO EQUIPMENT GUIDE This guide contains general information about NSA approved cryptographic devices that are currently available through the Commercial COMSEC Equipment Program (CCEP) or by direct purchase from NSA. Contractors for DOE must have a properly executed Controlled Cryptographic Item agreement with NSA. This guide is not intended to be a complete source of information but rather a summary. The information herein is only in sufficient detail to familiarize the reader with the basic capabilities of the equipment. Please note that the purchase and use of any product identified as "embeddable" requires prior DOE headquarters approval. A Memorandum of Agreement (MOA) with NSA must be properly executed in cases where a DOE or DOE contractor/ supplier proposes to use embedded products for classified operations. NETWORK EMBEDDED OPTICAL DATALINK STU OTHER MISSI Network Encryption Equipment CANEWARE NETWORK ENCRYPTION SYSTEM WANG TRUSTED LAN INTERFACE UNIT FASTLANE ATM ENCRYPTOR CANEWARE CANEWARE is a host-to-host network encryption system designed to provide multi-level security on a packet switched network. It is compatible with Secure Data Network System (SDNS) standards and is transparent to network operations. The CANEWARE system consists of a CANEWARE Front End (CFE) unit, a CANEWARE Control Processor (CCP) unit, and an Auxiliary Vector Management System (AVMS). The AVMS augments the SDNS Electronic Key Management System (EKMS) Mandator Access Control (MAC) information by distributing additional security attributes. The EKMS information and additional security attributes from the AVMS along with Discretionary Access Controls (DAC) from the CCP are used by the CFEs to enforce access controls to the network. The CFE also provides data encryption on communication links. A CFE is required at each network point. The CCP is used to provide DAC information to the CFEs. DAC information is used by the CFE to limit access to each host based on need-to-know information provided by the host to the CCP. A single CCP can control up to 5000 CFEs, which is the maximum number for a single domain. Up to 1000 domains can be supported by the CANEWARE system. CANEWARE is capable of encrypting and decrypting at through put rates from 1200 bps to 750 kbps full duplex and supports I/O rates up to the T1 rate (1.544 Mbps). It supports standard protocols such as GOSIP X.25, DDN X.25 and CCITT 1984 X.25. The standard KSD-64A is used for loading configuration information and initial keying material. It also serves as a crypto ignition key for the CFE. A multi-level security host encryption system functions on X.25, IEEE 802.3, and Ethernet packets switched networks. The CANEWARE system is approved for use at all classification levels.. The development program is complete. They are currently establishing production requirements. The approximate cost is $19,500. NETWORK ENCRYPTION SYSTEM The Motorola Network Encryption System (NES) provides encryption security to local area networks (LANs) and Wide Area Networks (WANs). The NES is designed for system high data encryption and can accomodate multiple security communities through network partitioning into separate domains. It provides data confidentiality, data integrity, peer identification and authentication, and mandatory/discretionary access control services. The NES is configured at start up by a configuration disk created by the product server. A product server can be any IBM compatible personal computer. Each product server is capable of serving a maximum of 2000 NES platforms. The configuration disk created by the product server contains application software, discretionary access control (D
No Subject
-- Forwarded message -- Subject: Crypto Equipment Guide -- Part Three of Three Date: Mon, 17 May 1999 16:10:30 -0500 SECURE TERMINAL EQUIPMENT Secure Terminal Equipmet (STE) is the next generation STU-III being designed to provide services far beyond the present STU-III devices. The STE offers backward compatibility with STU-III, while taking advantage of digital communications protocols like ISDN and future ATM. The initial release of STE will be an ISDN terminal. STE is designed to take advantage of the key and privilege management infrastructure developed under the Multi-level Information Systems Security Initiative (MISSI) Fortezza Plus Cards. The cryptographics for STE will be located on a removable Personal Computer Memory Card International Associate (PCMCIA) card. This card will be procured seperately. Secure Terminal Equipment serves as a secure voice and data communication. It has been planned for use at all classification levels. The vendor is Lockheed Martin and Motorola Government Systems. Other Encryption Equipment CONDOR ATT SECURE CONFERENCE SYSTEM SSP3110 DATA STORAGE ENCRYPTOR DATA TRANSFER DEVICE CONDOR The Condor is an effort to produce a security solution for commercial digital wireless systems. This includes cellular, mobile satellite, and personal communications systems. It is being designed to utilize the Fortezza Plus cryptographic card. The CONDOR provides secure communications for commercial wireless services (CDMA cellular and Mobile Satellite). This product is currently under development. The CDMA (dual mode cellular) will be completed in March, 1998, Globalstar in August, 1998 and Iridium in August, 1998. The authorized vendor and cost is undetermined at this time. ATT SECURE CONFERENCE SYSTEM The ATT Secure Conference System consists of a circuit board installed in a personal computer, a STU-III terminal, and a switch box connected at the host site. This configuration functions as a concentrator during a secure conference call. The circuit board can be installed in a 386 or 486 personal computer. The system requires a minimum of 640 K of RAM and MS-DOS 3.0 or higher to operate. A telephone conference can be provided for up to four secure terminals per circuit board. Multiple circuit boards may be installed in one computer to raise the number of secure terminals to a maximum of 12 units. The ATT Secure Conference System can function with any STU-III devices at 2400 bps and 4800 bps in half duplex communication mode. Crypto-ignition keys are used at the STU-III terminal as usual. The computer with the circuit board installed will verify each participants clearance prior to initiating the conference. This system is approved for use at all classification levels. The authorized vendor is ATT Secure Communications Products. Contact the vendor for the cost. SSP3110 DATA STORAGE ENCRYPTOR The SSP3110 encrypts sensitive data received from a host over the Small Computer Systems Interface (SCSI) and wrties it to a storage medium such as a floppy diskette, magnetic tape, or an optical disk. Stored data that is encrypted using this device may be treated as "unclassified". The maximum processing speed using the SSP3110 is 150 Kbps depending on the application. Electronic keying is accomplished using KEKs on punched paper tape and TEKs on Smart Keys. TEKs are derived from NSA-supplied floppy diskettes and written to Smart Keys using a Key Management Loader. In pairs, TEKs are used for Two- Stations transport aplications, shared TEKs are used for Multi-Station transport applications, and Special Purpose TEKs are used for data storage applications. KEK loading requires KOI-18 Tape Reader and DS-102 Signal Converter. The SSP3110 Data Storage Encryptor is approved for use at all classification levels. Tractor Aerospace has developed the Secure Retrieval Processor (SRP), which is a less expensive, decrypt-only, embeddable board-level companion to the SSP3110. The cost for the SSP3110 is $11,995, Key Loader Key Manager Software is $2,500, and Training is $3,000. The SRP price is not available. DATA TRANSFER DEVICE The Data Trans
No Subject
This I got from computer historian, Simon Lavington.
The (Manchester) Ferranti Mark I had a hardware random number generator.
This was specified by Alan Turing - (A copy of his original
Internal Report, dated 1949 I believe, still exists.) The random
number instruction was based on electron noise in a thermionic
diode. Turing's report even gives a possible circuit diagram.
The same strategy is used today in the UK Dept. of National
Savings' ERNIE Premium Bond machine.
Another curiosity of the Mark I's instruction set was a sideways
add ('population count'), also specified by Turing. I've always
assumed that the two instructions could be useful for cryptography -
eg for the generation of one-time coding pads and the testing of
decryption procedures.
No Subject
Crack open your palm pilots and take note! And please repost widely. Our mailing list ([EMAIL PROTECTED]), along with the rest of eff.org, is sadly out of commission. DC Cypherpunks will hold a meeting at the Electronic Privacy Information Center office in Washington, DC. DATE: Soon! Saturday, November 21, 1998 TIME: 5pm Featured speaker: Richard Schroeppel, University of Arizona [EMAIL PROTECTED] The Hasty Pudding Cipher "NIST is organizing the search for a new block cipher, the Advanced Encryption Standard. The Hasty Pudding Cipher is my entry in the AES competition. The design goals for HPC are medium security, speed, and flexibility. Hasty Pudding works with any block length and any key size. It is optimized for 64-bit architectures, operating at 200 MHz on large data blocks. Hasty Pudding introduces a new feature, Spice, which allows useful non-expanding encryption of small blocks, even single bits. The cipher includes some unusual design principles." Location: Electronic Privacy Information Center 666 Pennsylvania Ave. SE, at the corner of Pennsylvania and 7th in South East DC Across the street from Eastern Market Metro station (Orange Blue Line) To get into the building, go around to the 7th street side next to the flower shop and use the call box to call the EPIC office. We'll buzz you in. True to DCCP form, we'll probably hit a local resturaunt afterwards for dinner. If you need more explicit directions, please contact Kathleen Ellis at (202)298-0833 or [EMAIL PROTECTED] For more information about the DC Cypherpunks, see our web page at http://www.isse.gmu.edu/~pfarrell/dccp/index.html
