Encryption of data in smart cards
Hello, Can anyone point me to sources about encryption of data in smart cards. What I am looking for is protocols for encrypting sensitive data (e.g., medical information about the card-holder), so that even if the card falls into malicious hands, it won't be easy to read that data. Thank you, Raghavendra. -- N. Raghavendra [EMAIL PROTECTED] | OpenPGP public key available Tata Consultancy Services| at http://www.keyserver.net/ Hyderabad| Key ID: 0x03618806 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Active Countermeasures Against Tempest Attacks
At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: On the other hand, remember that the earliest Tempest systems were built using vacuum tubes. An attacker today can carry vast amounts of signal processing power in a briefcase. And while some of the signal processing jobs need to scale with the target systems, as computer clock speeds get faster, the leakage gets higher and therefore shielding becomes harder and leakage gets higher. Most of the older shielding systems can do fine with the 70 MHz monitor speeds, but the 3 GHz CPU clock speed is more leaky. Millimeter wavelengths are _much_ more annoying. All in all I would not put much faith in ad hoc Tempest protection. Without access to the secret specifications and test procedures, I would prefer to see highly critical operations done using battery powered laptops operating in a Faraday cage, with no wires crossing the boundary (no power, no phone, no Ethernet, nada). In that situation, one can calculate shielding effectiveness from first principles. http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt suggests US government requirements for a shielded enclosure are 60 db minimum. Back when most of the energy lived at a few MHz, it was easy to make enclosures that had air vents that didn't leak useful amounts of signal. It's harder today. So take your scuba gear into your Faraday cage with you :-) Basically, if you've got a serious threat of TEMPEST attacks, you've got serious problems anyway... - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: double shot of snake oil, good conclusion
Tal, I am in full agreement with your opinion. I do not think security is an all or nothing property, and I do think that mechanisms can be considered effective even if they do not protect against attackers with some level of skill or motivation. After all, there is no complete security and security is, and has always been, considered as perceived assurance. I do not think that a fact that a mechanism can be somehow circumvented makes it useless. Keepng the honest people honest is a good enough legitimation for a mechanism to exist as well as moving the bar higher. However, the only problem I can see in this case is the opening of a possibility of a false sense of security. Security mechanisms do not have to be perfect, but their perceived strength by their users shall be set right. For this I personally think that the mechanism is great and useful, but should be presented by Microsoft accordingly, hence: as a useful security-related feature, not as a complete bullet-proof protection tool. Hagai. Hagai Bar-El - Information Security Analyst Tel.: 972-8-9354152 Fax.: 972-8-9354152 E-mail: [EMAIL PROTECTED] Web: www.hbarel.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
Ben Laurie writes: I actually just finished finding the 16384 bit Diffie-Helman group with same kind of parameters. It took about 9.5 months to generate. The 12288 bit group took only about 15 days to generate. I have to admit to surprise at the time involved - what s/w are you using to do the generating? We have our own software and crypto library to generate those primes. To create ~500 bit group it takes about 10 seconds. To create ~1000 bit group it takes about minute. Here are ike style primes between 512-1024 where the bits is incremented by 32 every time. These are not proven, but running primo or similar on them shouldn't take that long, so you can do it yourself if you need a proven prime: SOPHIE GERMAIN PRIME SEARCH FIXED 64 bits. INDEX 0: PRIME (bits 512), index = 131, 0.989151 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d PRIME (bits 544), index = 11486, 2.32198 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b374a PRIME (bits 576), index = 145480, 17.2525 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df2614c7e PRIME (bits 608), index = 37293, 5.66688 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1c719 PRIME (bits 640), index = 335775, 42.4739 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d56e1e3 PRIME (bits 672), index = 5214, 2.83781 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485c9d3 PRIME (bits 704), index = 65808, 10.8744 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625f7fd5 PRIME (bits 736), index = 229946, 34.0901 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44fc522 PRIME (bits 768), index = 149686, 24.5593 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a63a3620 PRIME (bits 800), index = 168625, 28.5964 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0c01ef66 PRIME (bits 832), index = 13056, 5.62474 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406eaec PRIME (bits 864), index = 173063, 32.9709 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee3b1001 PRIME (bits 896), index = 26718, 9.01863 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a8a0802 PRIME (bits 928), index = 636907, 119.4 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5aea8dbfb PRIME (bits 960), index = 139761, 31.0893 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4d41d6 PRIME (bits 992), index = 15349, 8.29022 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d51c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899fa5ae9f24117c4b1fe64928a245 FINISHED (0 primes found in the interval 512 to 1024). -- [EMAIL PROTECTED] SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkithttp://www.ssh.fi/ipsec/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe
Khalid Sheikh Mohammed caught partially by Echelon?
The guardian reports (unsurprisingly) that Echelon was used in tracking Khalid Sheikh Mohammed's mobile phones: http://www.guardian.co.uk/alqaida/story/0,12469,911860,00.html -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Active Countermeasures Against Tempest Attacks
At 11:43 PM -0800 3/10/03, Bill Stewart wrote: At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: On the other hand, remember that the earliest Tempest systems were built using vacuum tubes. An attacker today can carry vast amounts of signal processing power in a briefcase. And while some of the signal processing jobs need to scale with the target systems, as computer clock speeds get faster, the leakage gets higher and therefore shielding becomes harder and leakage gets higher. Most of the older shielding systems can do fine with the 70 MHz monitor speeds, but the 3 GHz CPU clock speed is more leaky. Millimeter wavelengths are _much_ more annoying. All in all I would not put much faith in ad hoc Tempest protection. Without access to the secret specifications and test procedures, I would prefer to see highly critical operations done using battery powered laptops operating in a Faraday cage, with no wires crossing the boundary (no power, no phone, no Ethernet, nada). In that situation, one can calculate shielding effectiveness from first principles. http://www.cs.nps.navy.mil/curricula/tracks/security/AISGuide/navch16.txt suggests US government requirements for a shielded enclosure are 60 db minimum. Back when most of the energy lived at a few MHz, it was easy to make enclosures that had air vents that didn't leak useful amounts of signal. It's harder today. So take your scuba gear into your Faraday cage with you :-) One of my pet ideas is to used older, 1990's vintage, laptops for secure processing, e.g. reading PGP mail, generating key pairs, signing submaster keys, etc. They are cheap enough to dedicate to the task, they'd be off most of the time thereby reducing vulnerability, older operating systems and firmware have fewer opportunities for mischief and most viruses won't run on the old software. Easier shielding due to lower clock rate is an advantage I hadn't thought of before. Basically, if you've got a serious threat of TEMPEST attacks, you've got serious problems anyway... You could say that about strong crypto in general. Anyone with valuable information stored on a computer has lots to worry about. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
--- Tero Kivinen [EMAIL PROTECTED] wrote: SOPHIE GERMAIN PRIME SEARCH FIXED 64 bits. INDEX 0: PRIME (bits 512), index = 131, 0.989151 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d What is the benefit of having leading/trailing bits fixed? As far as I know it doesn't make any form of index calculus attack any harder to apply. Tom __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
- Original Message - From: tom st denis [EMAIL PROTECTED] To: Cryptography [EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 11:28 AM Subject: Re: Proven Primes --- Tero Kivinen [EMAIL PROTECTED] wrote: SOPHIE GERMAIN PRIME SEARCH FIXED 64 bits. INDEX 0: PRIME (bits 512), index = 131, 0.989151 seconds: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b 139b22514a08798e3404ddef9519b3cd3a439d What is the benefit of having leading/trailing bits fixed? As far as I know it doesn't make any form of index calculus attack any harder to apply. No, but you can speed up modulo multiplication. The OAKLEY RFC says: The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. At one point in time some of my colleagues got the optimization with the high order bits set to 1 in C code going on very well, I don`t remember if we implemented the optimization with the low order bits set to 1. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Active Countermeasures Against Tempest Attacks
Date: Mon, 10 Mar 2003 23:43:28 -0800 From: Bill Stewart [EMAIL PROTECTED] At 09:14 AM 03/10/2003 -0500, Arnold G. Reinhold wrote: On the other hand, remember that the earliest Tempest systems were built using vacuum tubes. An attacker today can carry vast amounts [...snip...] Basically, if you've got a serious threat of TEMPEST attacks, you've got serious problems anyway... Actually, quite a bit of the TEMPEST framework is not stopping an adversary from reading what you have on your CRT (or display), but denying the adversary the wherewithal for figuring out that you ARE there. It would really be the pits to have someone standing off over the horizion and saying... Hm-m-m... 70Mhz over THERE? Why is a monitor over THERE? There shouldn't be ANYTHING over THERE... Hm-m-m.. Who do we know that uses... Well, you get the idea. TEMPEST equipment is specially shielded so that it does not leak ANY RF energy that can be picked up on RF direction finding equipment. --- Gregory Hicks| Principal Systems Engineer Cadence Design Systems | Direct: 408.576.3609 555 River Oaks Pkwy M/S 6B1 | Fax: 408.894.3400 San Jose, CA 95134 | Internet: [EMAIL PROTECTED] The trouble with doing anything right the first time is that nobody appreciates how difficult it was. When a team of dedicated individuals makes a commitment to act as one... the sky's the limit. Just because We've always done it that way is not necessarily a good reason to continue to do so... Grace Hopper, Rear Admiral, United States Navy - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Proven Primes
tom st denis writes: 0xc90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63b139b22514a08798e3404ddef9519b3cd3a439d What is the benefit of having leading/trailing bits fixed? Those primes are generated using the rules defined in the RFC 2412. As far as I know it doesn't make any form of index calculus attack any harder to apply. High order bits makes classical remainder algorithms faster, and low order bits helps the Mongomery-style algoritms. From the RFC 2412: -- Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] -- [EMAIL PROTECTED] SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkithttp://www.ssh.fi/ipsec/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[IP] Inter-University Competition in Information Assurance
--- begin forwarded text Status: RO User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 11 Mar 2003 02:27:40 -0500 Subject: [IP] Inter-University Competition in Information Assurance From: Dave Farber [EMAIL PROTECTED] To: ip [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] From: tim finin [EMAIL PROTECTED] Subject: Inter-University Competition in Information Assurance To: [EMAIL PROTECTED] Date: Mon, 10 Mar 2003 21:30:44 -0500 Organization: UMBC http://umbc.edu/ Dave -- IPers in the Baltimore-Washington area might be interested in this talk. Tim -- 2003 CAPITAL-AREA SEMINAR ON INFORMATION ASSURANCE UMBC Center for Information Security and Assurance University of Maryland, Baltimore County An Inter-University Competition in Information Assurance: The Cyber Defense Exercises Lt. Colonel Dan Ragsdale U.S. Military Academy, West Point, NY Friday 14 March 2003 Lunch 11:30, Skylight Lounge, UMBC Commons Talk 1:00pm, Lecture Hall V, Engineering and Computer Science During the spring of 2001 and 2002, student teams at the five United States Service Academies participated in a Cyber Defense Exercise (CDX). Prior to each exercise an identical network of servers and workstations was set up at each school. During the first phase, teams of cadets and midshipmen at each site installed and configured an assortment of required services. The goal for each team during this phase was to configure the required service and the underlying operating systems in the most secure manner possible. In the second phase, an NSA-led penetration team attacked each site. This team Red Team, conducted detailed reconnaissance and voluminous attacks over a five-day period. They maintained accurate records of any and all successful penetrations. A White Team from CERT at Carnegie Mellon University refereed the exercise; they served as observers and controllers and, using an agreed upon scoring system, determined which school won. Personal observation and interviews with students and faculty show that the CDX is an extraordinary educational experience. This talk will address in detail some of the benefits and challenges of conducting such an exercise. Lt. Colonel Dan Ragsdale is director of the Information Technology and Operations Center (ITOC) at the US Military Academy (USMA) at West Point, NY. He has over twenty-one years of military and information technology experience, including seven years in the area of Information Assurance (IA). This past summer, Lt. Colonel Ragsdale participated in Operation Enduring Freedom in Afghanistan, where he served as the Chief of Assessment for the Combine and Joint Task Force (CJTF-80). In addition, he has been a frequent speaker and panelist at national IA conferences, and he has published numerous articles on IA topics. He earned a PhD from Texas AM. His current research interests include information assurance, network security, intrusion detection, and artificial intelligence Host: Dr. Alan T. Sherman, [EMAIL PROTECTED], Director, UMBC CISA. http://cisa.umbc.edu/. Directions: Take Exit 47B off I-95, and follow signs to UMBC. Park in visitor's lot. -- - You are subscribed as [EMAIL PROTECTED] To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ --- 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]
Groove shills for the DoD: Kapor quits board
Software Pioneer Quits Board of Groove By JOHN MARKOFF SAN FRANCISCO, March 10 Mitchell D. Kapor, a personal computer industry software pioneer and a civil liberties activist, has resigned from the board of Groove Networks after learning that the company's software was being used by the Pentagon as part of its development of a domestic surveillance system. http://www.nytimes.com/2003/03/11/business/11PRIV.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
