Reversible data hiding
--- begin forwarded text Status: RO Date: Mon, 23 Sep 2002 21:39:53 -0400 To: undisclosed-recipient:; From: Monty Solomon [EMAIL PROTECTED] Subject: Reversible data hiding Xerox, University of Rochester Researchers Discover Better Way to Embed, Remove Hidden Data in Digital Images - Sep 23, 2002 09:34 AM (BusinessWire) ROCHESTER, N.Y.--(BUSINESS WIRE)--Sept. 23, 2002--Scientists from the University of Rochester and Xerox Corporation (NYSE:XRX) have invented a new way to hide information within an ordinary digital image and to extract it again -- without distorting the original or losing any information. Called reversible data hiding, the new technique will solve a dilemma faced by digital image users, particularly in sensitive military, legal and medical applications. Until now they have had to choose between an image that's been watermarked to establish its trustworthiness and one that isn't watermarked but preserves all the original information, allowing it to be enlarged or enhanced to show detail. When information is embedded using the newly discovered method, authorized users can do both. The technique, described in a paper that will be presented at the IEEE 2002 International Conference on Image Processing here on Sept. 24, was co-developed by Mehmet U. Celik and A. Murat Tekalp of the university and Gaurav Sharma and Eli Saber of Xerox. Their collaborative research was done in the Center for Electronic Imaging Systems (CEIS), a New York State Office of Science, Technology and Academic Research designated center for advanced technology. ... - http://finance.lycos.com/home/news/story.asp?story=28782313 --- 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]
Re: Sun donates elliptic curve code to OpenSSL?
Greg Broile wrote: in the OpenSSL library, provided that the people who don't want to be sued comply with a list of conditions: : (2) don't modify Sun's code as provided by Sun, don't use only parts of the donated code, and don't remove the license text from the code. I think this (2) is misunderstanding, or may lead misunderstand. For example, i) of 3) describes that modifed part of the code (i.e. modified since Sun's contribution) is not subject of the covenant. But licensee who modifies Sun's code can covenant to Sun about the unmodified part of the code. -- soda - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sun donates elliptic curve code to OpenSSL?
Markus Friedl wrote: On Mon, Sep 23, 2002 at 02:50:20PM +0100, Ben Laurie wrote: (1) they promise not to sue Sun for infringing any of their own patents which might cover the use of the donated code (2) don't modify Sun's code as provided by Sun, don't use only parts of the donated code, and don't remove the license text from the code. Note that if you don't want to be bound by Sun's licence, there's a flag to remove all their donated code (at least, there's supposed to be, I haven't checked). This is a very bad move, especially since the code and copyright in question are spread all over the source tree. so a flag does not really help. You still have to 'use' the source files for building libssl. Actually, the flag does help (and it defaults off, I'm told). With this code OpenSSL is turning into a non-free project. Thank you very much. Thank you for moving patent litigation licenses into OpenSSL. As has been observed elsewhere, the patent stuff only applies if you make a similar promise to Sun. If you don't want to have Sun not sue you when you infringe, then don't promise not to sue them. Have you actually read the licence? 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: Sun donates elliptic curve code to OpenSSL?
On Tue, 24 Sep 2002, Bodo Moeller wrote: On Tue, Sep 24, 2002 at 01:29:29PM +0100, Ben Laurie wrote: Markus Friedl wrote: With this code OpenSSL is turning into a non-free project. As has been observed elsewhere, the patent stuff only applies if you make a similar promise to Sun. If you don't want to have Sun not sue you when you infringe, then don't promise not to sue them. Here's a longer explanation. The Sun code in OpenSSL 0.9.8-dev is available under the OpenSSL license; additionally, you have the *option* to accept the covenant: The ECC Code is licensed pursuant to the OpenSSL open source license provided below. In addition, Sun covenants to all licensees who provide a reciprocal ^^ covenant with respect to their own patents if any, not to sue under current and future patent claims necessarily infringed by the making, using, practicing, selling, offering for sale and/or otherwise disposing of the ECC Code as delivered hereunder (or portions thereof), provided that such covenant shall not apply: [...] That's a defining relative clause. If you are not willing to provide a reciprocal covenant, this has nothing to do with you. You just can't use the stuff patented by Sun, but it's not compiled in by default anyway for exactly this reason. Read it again. The first two words of the second sentence you quoted are, In addition... As I understand it, this means the donated code is available under the OpenSSL source license. So you *can* use it, whether or not it's patented by Sun. *In addition* to that, *if* you have software patents and you promise not to sue Sun over them because of an infringement you find in the donated code, then Sun promises that it won't sue you either. Sun does not forbid people from using the donated code on the basis of whether or not they make this promise. Basically, they're offering something they didn't have to offer in order to release it under the OpenSSL license; if they'd simply released it under the OpenSSL license, you'd have fewer options, not more. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Don Coppersmith questions Courtois and Pieprzyk AES results
Don Coppersmith questions Courtois and Pieprzyk AES results -- see: http://makeashorterlink.com/?K27C515E1 -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Sun donates elliptic curve code to OpenSSL?
*In addition* to that, *if* you have software patents and you promise not to sue Sun over them because of an infringement you find in the donated code, then Sun promises that it won't sue you either. Sun does not forbid people from using the donated code on the basis of whether or not they make this promise. By the way, OpenSSL has always included patented algorithms such as RSA and IDEA, together with warnings about patent issues in the documentation and compile time switches to disable algorithms that are known to be patented. In that sense, OpenSSL as a whole has never been free software. The licensing terms for IDEA actually are way more restrictive than those for Sun's ECC code, and nobody has complained about that so far - because many people find that code useful, and the others just disable it. -- Ulf Möller * Munich, Germany * E-Mail: ulfm AT epost.de - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
In message [EMAIL PROTECTED], [EMAIL PROTECTED] .cmu.edu writes: Perry E. Metzger wrote: An idea from some folks at MIT apparently where a physical token consisting of a bunch of spheres embedded in epoxy is used as an access device by shining a laser through it. I can't dig up the memory, but I think I heard of a similar idea -- random structure in transparent solid, difficult to copy -- used in some kind of tag or seal for nuclear security. Can anyone remind me what this might have been? A fair number of years ago, I saw something like this proposed for non-proliferation seals on nuclear reactors. The scheme then (I believe I saw it in Science News) was that International Atomic Engergy Agency inspectors would use a length of randomly-twisted multi-strand fiber optic cable and use it to seal a door that they opened to verify that the reactor in question wasn't being used to build weapons. They then shine a light in one end, and photograph the other. When they come back, the repeat the photographic process, so that they can see if anyone has removed their seal -- say, to get at the irradiated, plutonium-containing fuel rods. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
At 5:11 PM -0700 9/20/02, David Wagner wrote: Perry E. Metzger wrote: But if you can't simulate the system, that implies that the challenger has to have stored the challenge-response pairs because he can't just generate them, right? That means that only finitely many are likely to be stored. Or was this thought of too? I believe the idea is that there are gazillions of possible challenges. The challenger picks a thousand randomly in advance, scans the token from the corresponding thousand different angles to get the thousand responses, and stores all them. Then, later, the challenger can select one of his stored challenges, pass it to a remote entity, and demand the correct answer. Of course, a challenger must never re-use the same challenge twice. If the challenger selects several of his stored challenges, and asks the token reader to return a secure hash of the answers (in order), no information will be leaked about the response to any individual challenge. This procedure will allow the challenger to perform a large number of verifications with a relatively small number of stored challenge-response pairs. Cheers - Bill - Bill Frantz | The principal effect of| Periwinkle -- Consulting (408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave. [EMAIL PROTECTED] | fair use. | Los Gatos, CA 95032, USA - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
Bill Frantz wrote: If the challenger selects several of his stored challenges, and asks the token reader to return a secure hash of the answers (in order), no information will be leaked about the response to any individual challenge. This procedure will allow the challenger to perform a large number of verifications with a relatively small number of stored challenge-response pairs. I don't think this works. A malicious reader could remember all the challenges it gets and record all the responses it measures (before hashing). If the number of possible challenges is small, the malicious reader might learn the entire challenge-response dictionary after only a few interactions. From that point on, the malicious reader would be able to spoof the presence of the token. (Of course, if malicious readers aren't a threat, then you don't need fancy uncloneable tokens. A simple cryptographic key written on a piece of paper suffices.) So I think you really do need to use a different challenge every time. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: unforgeable optical tokens?
It might be possible to get the same effect using a conventional silicon chip. I have in mind a large analog circuit, something like a multi-stage neural network. Random defects would be induced, either in the crystal growing process or by exposing the wafer at one or more stages with a spray of pellets or chemicals. The effect would be to cut wires and alter component values such as resistances, zener diode break down voltages, transistor gains. Critical parts of the circuit would be protected by a passivation layer or would simply designed with larger geometries to make them less sensitive. Multiple inputs would be driven by D/A converters, either in parallel or through a charge coupled analog shift register. There would be enough stuff' in the middle to make it impractical to characterize the entire circuit from the inputs. One could use very small geometries for the network and still get high circuit yield since defects are something we want. The advantage of this approach over a optical system is that it would be very easy to interface with existing technology -- smart cards, RF ID, dongles, etc. Arnold Reinhold - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Werner Koch wk@gnupg.org] GnuPG 1.2 released
To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: GnuPG 1.2 released From: Werner Koch [EMAIL PROTECTED] Mail-Followup-To: [EMAIL PROTECTED] Hello! We are pleased to announce the availability of a new stable release of GnuPG: Version 1.2.0 The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. This new release implements most of OpenPGP's optional features, has somewhat better interoperabilty with non-conforming OpenPGP implementations and improved keyserver support. Getting the Software GnuPG 1.2.0 can be downloaded from one of the *GnuPG mirror sites*. The list of mirrors can be found at http://www.gnupg.org/mirrors.html. See below for a list of mirrors already carrying this new released. On the mirrors you should find the follwing files in the *gnupg* directory: gnupg-1.2.0.tar.bz2 (1.8 MB) gnupg-1.2.0.tar.bz2.sig GnuPG 1.2 source compressed using BZIP2 and OpenPGP signature. gnupg-1.2.0.tar.gz (2.5 MB) gnupg-1.2.0.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.0.7-1.2.0.diff.gz (1.0 MB) A patch file to upgrade a 1.0.7 GnuPG source. This file is signed; you have to use GnuPG 0.9.5 to verify the signature. GnuPG has a feature to allow clear signed patch files which can still be processed by the patch utility. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.2.0.zip (1.0 MB) gnupg-w32cli-1.2.0.zip.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. Note that this is a command line version and comes without a graphical installer tool. You have to use an UNZIP utility to extract the files and install them manually. The included file README.W32 has further instructions. Checking the Integrity == In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.2.0.tar.bz2 you would use this command: gpg --verify gnupg-1.2.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Never use a GnuPG version you just downloaded to check the integrity of the source - use an existing GnuPG installation. * If you are not able to use an old version of GnuPG, you have to verify the MD5 checksum. Assuming you downloaded the file gnupg-1.2.0.tar.bz2, you would run the md5sum command like this: md5sum gnupg-1.2.0.tar.bz2 and check that the output matches the first line from the following list: b22b10dacfeb5c2b0bc4ce9def2d1120 gnupg-1.2.0.tar.bz2 e93ceafc4395d1713d20044d523d18a7 gnupg-1.2.0.tar.gz c735a9a4400e3e3b0b78f88aadedfd3d gnupg-1.0.7-1.2.0.diff.gz af439e3ba82c8648041e8e9d902c3c01 gnupg-w32cli-1.2.0.zip Upgrade Information === The name of the default configuration file has changed from options to gpg.conf. The old name will still be used as long as no gpg.conf exists. We recommend to rename your file after the installation. If you are upgrading from a version prior to 1.0.7, you may want to run the command gpg --rebuild-keydb-caches once to speed up the keyring access. Please note also that due to a bug in versions prior to 1.0.6 it won't be possible to downgrade to such versions unless you use the GnuPG version which comes with Debian's Woody release or you apply the patch http://www.gnupg.org/developer/gpg-woody-fix.txt . If you have any problems, please see the FAQ and the mailing list archive at http://lists.gnupg.org. Please direct questions to the [EMAIL PROTECTED] mailing list. What's New === Here is a list of major user visible changes since 1.0.7: Configuration: * The default configuration file is now ~/.gnupg/gpg.conf. If an old ~/.gnupg/options is found it will still be used. This change is required to have a more consistent naming scheme with forthcoming tools. * The configure option --with-static-rnd=auto allows to build gpg with all available
