Re: smartcards
Quoting Trei, Peter ([EMAIL PROTECTED]): The phone SW world is nowhere near as closed as you think. * Thousands of developers are writing Java applets for Japanese iMode phones. * Hundreds are developing applets for the Blackberry 5810 and 5820 phones (free Java-based IDS from RIM). * Similarly, the high end Pocket PC and Palm phones both have free or inexpensive development environments (C/C++) * Finally, Qualcomm phones support BREW (free SDK, expensive training). I stand corrected. I'm even reading a short bit about Nokia's new 3g phone: http://www.theregister.co.uk/content/54/27310.html The device, known as the Nokia 6650, is also notable for allowing users to record up to 20 seconds of video (128x96 pixels) with sound using a built in VGA camera employing 4096 colours, the first Nokia phone to offer the facility Other features include a multimedia messaging service (MMS) client, a WAP 1.2.1-compatible browser, integrated Bluetooth, a wallet application for mobile transactions, and a Java 2 Micro Edition (J2ME) virtual machine based on the mobile information device profile (MIDP). Includes infrared and USB as well. Not much quickly available describing the wallet app, but it probably isn't peer-to-peer. My take on the situation is that the platform vendors are so anxious to get developer mindshare, and new apps, that they are for the most part giving away the development environments and specs. IOW, a decent number of platforms are ready to go. Cool. Regards, Steve
Re: Real-world steganography
--On Monday, 30 September, 2002 22:15 -0500 Jeremey Barrett [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Krumviede wrote: | i've seen comments in reviews of professional CD mastering | gear that there are other, seemingly preferred, technologies, | although i've never found details of them. | The other formats of note are probably SACD and then DVD-Audio. SACD is multichannel 16-bit/44.1kHz... so multichannel CD without additional sample resolution (if I recall). SACD is not backwards compatible though, whereas HDCD is. although we're wandering a bit far afield here, the other other format(s) i was referring to are all supposedly backwards compatible, with the original CD spec (wasn't that also some colored book?). i couldn't tell from the review, or don't remember, what, if anything, they required on the decoder side (but if they didn't require anything, then could it be steganography?). -paul
Re: Real-world steganography
Peter Gutmann wrote: I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. I don't think that's really 'steganography' per se, since no attempt is made to hide the fact that the information is in there. The quasi-stego used is just to prevent bad audio artifacts from happening. -Bram Cohen Markets can remain irrational longer than you can remain solvent -- John Maynard Keynes
Real-world steganography
I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. According to the vendors, HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY nominations, so it's already fairly widely deployed. From http://www.hdcd.com/partners/proaudio/overview.html: [...] Hidden Code Addition/Output Dither/Quantization The final step in the reduction to 16 bits is to add high-frequency weighted dither and round the signal to 16-bit precision. The dither increases in amplitude in the frequency range of 16 to 22.05 kHz, leaving the noise floor flat below 16 kHz where the critical bands of hearing associated with tonality occur. As part of the final quantization, a pseudo-random noise hidden code is inserted as needed into the least significant bit (LSB) of the audio data. The hidden code carries the decimation filter selection and Peak Extend and Low Level Range Extend parameters. Inserted only 2?5 percent of the time, the hidden code is completely inaudible-effectively producing full 16-bit undecoded playback resolution. The result is an industry-standard 44.1-kHz, 16-bit recording compatible with all CD replication equipment and consumer CD players. [...] The paper describing the process is available under the somewhat misleading name http://www.hdcd.com/partners/proaudio/AES_Paper.pdf. The description of the stego en/decoding process is on p.15 (it's a rather long excerpt, but it's interesting stuff): As part of the final quantization, a hidden code side channel is inserted into the LSB when it is necessary for the encoder to inform the decoder of any change in the encoding algorithm. It takes the form of a pseudo-random noise encoded bit stream which occupies the least significant bit temporarily, leaving the full 16 bits for the program material most of the time. Normally, the LSB is used for the command function less than five percent of the time, typically only one to two percent for most music. Because the hidden code is present for a small fraction of the time and because it is used as dither for the remaining 15 bits when it is inserted, it is inaudible. This was confirmed experimentally with insertion at several times the normal fraction of time. [...] The mechanism which allows insertion of commands only when needed consists of encapsulating the command word and parameter data in a packet. A synchronizing pattern is prepended to the data and a checksum is appended. The resulting packet is then scrambled using a feedback shift register with a maximal length sequence and inserted serially, one bit per sample, into the LSB of the audio data. The decoder sends the LSB's of the audio data to a complementary shift register to unscramble the command data. A pattern matching circuit looks for the synchronizing pattern in the output of the descrambler, and when it finds it, it attempts to recover a command. If the command has a legal format and the checksum matches, it is registered as a valid packet for that channel. The arrival of a valid packet for a channel resets a code detect timer for that channel. If both channels have active timers, then code is deemed to be present and the filter select data is considered valid immediately. However, any command data which would effect the level of the signal must match between the two channels in order to take effect. The primary reason for this is to handle the case where an error on one channel destroys the code. In such a case, the decoder will mistrack for a short time until the next command comes along, which is much less audible than a change in gain on only one channel, causing a shift in balance and lateral image movement. If either of the code detect timers times out, then code is deemed not to be present, and all commands are canceled, returning the decode system to its default state. If the conditions on the encoder side are not changing, then command packets are inserted on a regular basis to keep the code detect timers in the decoder active and to update the decoder if one starts playing a selection in the middle of a continuous recording. Since the decoder is constantly scanning the output of the de-scrambler shift register for valid command packets even when none are present, the possibility exists that there may be a false trigger. For audio generated by the encoder, this possibility is eliminated in the absence of storage and transmission errors by having the encoder scan the LSB of the audio data looking for a match. If a match to the synchronizing pattern is found, the encoder inverts one LSB to destroy it. Modern digital storage and transmission media incorporate fairly sophisticated error detection and correction systems. Therefore, we felt that only moderate precautions were necessary in
Re: Real-world steganography
On Mon, Sep 30, 2002 at 07:31:19PM -0700, Paul Krumviede wrote: | --On Tuesday, 01 October, 2002 13:54 +1200 Peter Gutmann | [EMAIL PROTECTED] wrote: | | I recently came across a real-world use of steganography which hides extra | data in the LSB of CD audio tracks to allow (according to the vendor) the | equivalent of 20-bit samples instead of 16-bit and assorted other | features. According to the vendors, HDCD has been used in the recording | of more than 5,000 CD titles, which include more than 250 Billboard Top | 200 recordings and more than 175 GRAMMY nominations, so it's already | fairly widely deployed. ... | i've seen comments in reviews of professional CD mastering | gear that there are other, seemingly preferred, technologies, | although i've never found details of them. The two that spring to mind are HDCD and XRCD. I'd never dug into how they're recorded, being much more interested in playing with things closer to the output stage, like speaker resonance control and electrical hum elimination... Adam -- It is seldom that liberty of any kind is lost all at once. -Hume
Re: What email encryption is actually in use?
James A. Donald [EMAIL PROTECTED] writes: To the extent that real people are using digitally signed and or encrypted messages for real purposes, what is the dominant technology, or is use so sporadic that no network effect is functioning, so nothing can be said to be dominant? For encryption, STARTTLS, which protects more mail than all other email encryption technology combined. See http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf (towards the back). For signing, nothing. The S/MIME list debated having posts to the list signed, and decided against it: If I know you, I can recognise a message from you whether it's signed or not. If I don't know you, whether it's signed or not is irrelevant. That leaves a few highly specialised applications which don't really qualify as use by real people (e.g. pgpmoose, EDI, etc etc, where any random proprietary format is fine, since it's decided by mutual agreement of both parties). Peter.
Re: Real-world steganography
--On Tuesday, 01 October, 2002 13:54 +1200 Peter Gutmann [EMAIL PROTECTED] wrote: I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. According to the vendors, HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY nominations, so it's already fairly widely deployed. maybe. i'm not sure how many players support it (my spectral D/A convertor does, but then some of the people at spectral seem to have invented HDCD). while the CDs i have that use it sound pretty good, i don't have any good way to compare them when played back over a non-HDCD capable convertor (i could hook up one of my computer CD drives, but that doesn't seem fair compared to the spectral transport-D/A combination). but when i do play such CDs on other gear, i don't notice any audible degradation, so it isn't obviously harmful. i've seen comments in reviews of professional CD mastering gear that there are other, seemingly preferred, technologies, although i've never found details of them. -paul
Clarification of challenge to Joseph Ashwood:
-- James A. Donald: (ranting on the user hostility of PGP) Presumably the theory underlying this brilliant design decision was that in the bad old days, a [signed clear text file signed] under unix would not verify under windows because of trivial differences such as the fact the whitespace is expressed slightly differently. Here is a better fix, one that I implemented in Kong: Define several signature types with the default signature type ignoring those aspects of the message that are difficult for the user to notice, so that if a message looks pretty much the same to the user, it has the same signature, by, for example, canonicalizing whitespace and single line breaks, and treating the hard space (0xA0) the same as the soft space. (0x20), and so on and so forth. Joseph Ashwood: So it's going to be broken by design. These are critical errors that will eliminate any semblance of security in your program. James A. Donald: I challenge you to fool my canonicalization algorithm by modifying a message to as to change the apparent meaning while preserving the signature, or by producing a message that verifies as signed by me, while in fact a meaningfully different message to any that was genuinely signed by me. Let see you doing some work to back up your empty words. The source code for my canonicalization code is on the net. If you say it is broken, break it! To clarify, Kong works by checking a signature against the message, and against other messages in its database. Its job is not to identify the true James Donald, but to keep the different people claiming to be James Donald clearly separated. Thus Kong would be broken if such separation could be obfuscated or confused. Any program attempting to determine whether Bob is someone's true name is attempting to do something that computers cannot do, hence the intolerable certificate management problems of software that attempts to do that. Three quarters of the user hostility of other programs comes from their attempt to support true names, and the rest comes from the cleartext signature problem. Kong fixes both problems. Joseph Ashwood must produce a message that is meaningfully different from any of the numerous messages that I have sent to cypherpunks, but which verifies as sent by the same person who sent past messages. Thus for Kong to be broken one must store a past message from that proflic poster supposed called James Donald, in the Kong database, and bring up a new message hacked up by Joseph Ashwood, and have Kong display in the signature verification screen The signature in this document matches the signature on another document signed by James A. Donald. Do you wish to view this document. While Kong display a document meaningfully different from any that was posted by James A. Donald. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG gQcEhL/Zl68mNm0WaeG7zRK5M+/3qbaE0t84hURH 4st/8mhjCyBBCy1Ganf3ud6SNdzLZtUChQQbTA6SO
Re: What email encryption is actually in use?
at Monday, September 30, 2002 7:52 PM, James A. Donald [EMAIL PROTECTED] was seen to say: Is it practical for a particular group, for example a corporation or a conspiracy, to whip up its own damned root certificate, without buggering around with verisign? (Of course fixing Microsoft's design errors is never useful, since they will rebreak their products in new ways that are more ingenious and harder to fix.) Yup. In fact, some IPSec firewalls rely on the corporate having a local CA root to issue keys for VPN access. from there it is only a small step to using the same (or parallel issued) keys for email security. The problem there really is that the keys will be flagged as faulty by anyone outside the group (and therefore without the root key already imported), and that will usually only work in a semi-rigid hierachical structure. There *is* an attempt to set up something resembling a Web of trust using x509 certificiates, currently in the early stages at nntp://news.securecomp.org/WebOfTrust I intended to sign this using Network Associates command line pgp, only to discover that pgp -sa file produced unintellible gibberish, that could only be made sense of by pgp, so that no one would be able to read it without first checking my signature. you made a minor config error - you need to make sure clearsign is enabled. I suggest that network associates should have hired me as UI design manager, or failing, that, hired the dog from down the street as UI design manager. It's command line. Most cyphergeeks like command line tools powerful and cryptic :)
Re: smartcards
Steve Thompson [EMAIL PROTECTED] writes: o Most of them have an IR port and many contain enough storage and horsepower to keep and play small MP3 collections. Chaumian digital cash code should fit easily. Hell, some companies are already making noises about full-motion video. How long before the damn things have a digital camera built in? They already do (at least in Europe) http://www.nokia.com/phones/7650/ and many are programmable in Java -- Steve Mynott [EMAIL PROTECTED]
Re: What email encryption is actually in use?
at Tuesday, October 01, 2002 3:08 AM, Peter Gutmann [EMAIL PROTECTED] was seen to say: For encryption, STARTTLS, which protects more mail than all other email encryption technology combined. See http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix02_slides.pdf (towards the back). I would dispute that - not that it isn't used and useful, but unless you are handing off directly to the home machine of the end user (or his direct spool) odds are good that the packet will be sent unencrypted somewhere along its journey. with TLS you are basically protecting a single link of a transmission chain, with no control over the rest of the chain. For signing, nothing. The S/MIME list debated having posts to the list signed, and decided against it: If I know you, I can recognise a message from you whether it's signed or not. Signing has a limited application - I wouldn't use it routinely other than to establish an association (key--poster) early in a conversation, and then omit it except for things whose source *I* would want verified if I was receiving it. It is unusual for me to use a sig outside of encrypt+sign. If I don't know you, whether it's signed or not is irrelevant. Depends on the definition of know. If a poster had a regular habit of posting at least one signed message every week, and had never protested that the sigs were faked, then you could assume that the poster whose sig just cleared is the same as the poster who has been posting for that time period - mapping that to any real-world individual is more problematic, but mostly you don't need to. There are plenty of people I only know online from email exchanges, and in some cases am not even sure what sex they are :)
Re: What email encryption is actually in use?
-- James A. Donald: I intended to sign this using Network Associates command line pgp, [6.5.8]only to discover that pgp -sa file produced unintellible gibberish, that could only be made sense of by pgp, so that no one would be able to read it without first checking my signature. David Howe you made a minor config error - you need to make sure clearsign is enabled. James A. Donald: I suggest that network associates should have hired me as UI design manager, or failing, that, hired the dog from down the street as UI design manager. David Howe It's command line. Most cyphergeeks like command line tools powerful and cryptic :) We also like the most common uses to be *on* the command line. If the option is not on the command line, it is *not* powerful and it is a little too cryptic. The pgp.cfg file is empty by default on my machine, the cfg file options are nowhere documented, clearsigning is nowhere documented, and Clearsign=on did not work. In the last generally useful version of pgp (pgp 2.6.2) pgp -sa gave clear signing, but it was unusable, because trivial differences, such as the unix/windows difference on carriage returns would cause the signature check to fail. Because there were so many false negatives, no one would check clearsigned signatures. I conjecture that in pgp 6.5.8 they have addressed this problem by making clear signatures as inaccessible as possible, rather than by fixing it. I could get clearsigning by telling my pgp 6.5.8 to be compatible with 2.6.2, but I have already discovered that 2.6.2 clear signing was hopelessly broken. Had clear signing worked, then everyone with a valuable domain name would have used the pgp interface to control their domain names, to ensure that one's domain name could not be hijacked, as so many domain names have been. This would have created a massive base of pgp users. However, due to architectural defects in pgp, design bugs rather than coding bugs, this use of pgp was broken, and so was seldom used, and eventually ceased to work entirely. Presumably there was no maintenance on the pgp inteface to domain name control, because no one was using it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG MUiyRJ8PRbLCXnVMWCpeKvsn5GdOlAB9t6O7K0Hb 4GBcVbBHZFN0vg8apVt35e9Y2khaPdgrM+Y6uOys6
XRCD HDCD
XRCD is not steganographic in the sense that we are disscusing, but merely a very carefully done 24 bit master mastered down to the normal 16x44 of CD. They also pay very careful attention to the physical manufacturing of the disc, and use aluminum as the substrate (instead of the normal audiophile gold). HDCD is a whole different ballgame, however. It indeed uses subcoded information and a form of spread-spectrum to add something like 1.5 bits of additional resolution to standard CDs. Played back on an HDCD-compatible player or DAC (there are plenty on the market now), the sound quality is noticeably superior, depending on the recording. (A good example is Perishable Fruit by Patty Larkin.) Peter Madnick (who was the desginer of the Audio Alchemy stuff) once told me that he used the HDCD DAC chip simply because it had the best filter characteristics of any chip available off-the-shelf. Conversely, HDCD recordings supposedly sound better even on non-HDCD-capable DACs for a similar reason. The odd thing is that Pacific Microsonics (who own HDCD) demands that all CD players or DACs that use the chip attenuate non-HDCD recordings by 3 dB. This is because HDCD recordings are on average 3dB quieter than their non-HDCD counterparts so that they appear to sound better in showrooms (it's well known that volume can give their appearence of superior sound quality). Forunately, they do also allow the manufacturer to include a attenuation-defeat feature so that the customer can defeat it at home (a lot of us believe that anything in the sound chain that is unnecessary is bad). (I've got such a feature on my Levinson DAC.) As for hearing the subcode, I can, on some recordings, but then again my dad folks and brothers are all pro musicians (yes, I claim to have golden ears). It's extremely hard to hear, and results in a VERY low level buzziness on some instruments and vocals. Over all, however, it's great. Go get the newer HDCD Red Remaster by King Crimson and compare it to the older non-HDCD master on and HDCD deck. You hear all sorts of details that you never could before. _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
Re: What email encryption is actually in use?
The problem Mr. Howe describes is fundamental, folks: encryption should be end-to-end even when the endpoints are functionaries in a company. Because not all employees are equal. So yes Alice at ABC.COM sends mail to Bob at XYZ.COM and the SMTP link is encrypted, so the bored upstream-ISP netops can't learn anything besides traffic analysis. But once inside XYZ.COM, many unauthorized folks could intercept Bob's email. Access Control is sorely lacking folks. Link encryption is a good idea, but rarely sufficient. At 01:20 PM 10/1/02 +0100, David Howe wrote: at Tuesday, October 01, 2002 3:08 AM, Peter Gutmann [EMAIL PROTECTED] was seen to say: For encryption, STARTTLS, which protects more mail than all other email encryption technology combined. See I would dispute that - not that it isn't used and useful, but unless you are handing off directly to the home machine of the end user (or his direct spool) odds are good that the packet will be sent unencrypted somewhere along its journey. with TLS you are basically protecting a single link of a transmission chain, with no control over the rest of the chain.
Re: What email encryption is actually in use?
At 11:52 AM 9/30/02 -0700, James A. Donald wrote: -- What email encryption is actually in use? PGP 5-7 on Win95+, using Eudora 3.05 talks to Mac whatever using 2.6.2 Signing is not generally necessary. The chief barrier to use of outlook's email encryption Outlook is one of Microsoft's Virus Engine Suite, isn't it?
fun w/ the SS chalk
After reading the last paragraph in the excerpt below, it occurs to me how much fun could be had in DC with some chalk, even without an 802.11blah receiver :-) http://www.siliconvalley.com/mld/siliconvalley/4181308.htm?template=contentModules/printstory.jsp Secret Service probes wireless networks in Washington WASHINGTON (AP) - Secret Service agents are putting a high-tech twist on the idea of a cop walking the beat. Using a laptop computer and an antenna fashioned from a Pringles potato chip can, they are looking for security holes in wireless networks in the nation's capital. The act of ``wardriving,'' a term taken from older ``wardialing'' programs that called random telephone numbers looking for unlisted modems, has become so prevalent that enthusiasts are using chalk marks on streets and sidewalks to point out networks in public places. Peterson said there has not been any reported ``warchalking'' in the Washington area yet, but if one was found agents would alert the network owner.
Re: Real-world steganography
On 2002-10-01, Ben Laurie uttered to Peter Gutmann: Yeah, right - and green felt-tip around the edges of your CD improves the sound, too. I'm not sure about HDCD as a technology, but the principle is sound. If we can compress sound transparently, we can also transparently embed quite a lot of data into the part which is perceptually irrelevant. We might also depart with perceptual equivalence and go with perceptual similarity instead -- e.g. multiband compress the audio, and embed data which allows us to expand to a higher perceptual resolution. Whatever the implementation, putting data in the gap between statistical (i.e. computed against a Markov model) and perceptual (against a perceptual similarity model) entropy which compensates for some of the perceptual shortcomings (like total dynamic range) of a particular recording technology seems like an excellent idea. However, applications like these have very little to do with steganography proper. In this case, we can (and want) to fill up the entire gap between statistical and perceptual entropy estimates with useful data, leaving us with signals which have statistical entropies consistently higher than we'd expect of a typical recording with similar perceptual characteristics. That is, the encoded signal will appear manifestly random compared to typical unencoded material from a similar source, and we can easily see there is hidden communication going on. Such encodings will be of little value in the context of industrial strength steganography used for hidden communication. Steganography used in the latter sense will also have to be imperceptible, true, but but here the entropic gap we're filling is the one between the entropy estimates of our best model of the source material vs. that of the adversary's. Be the models Markov ones, perceptual, something else, or composites of the above. Consequently the margin is much thinner (bandwidths are probably at least a decade or two lower), and the aims remain completely separate. Consequently, I don't believe encodings developed for the first purpose could ever be the best ones for the latter, or that HDCD-like endeavors really have that much to do with the subject matter of this list. -- Sampo Syreeni, aka decoy - mailto:[EMAIL PROTECTED], tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
Re: What email encryption is actually in use?
-- James A. Donald: I intended to sign this using Network Associates command line pgp, [6.5.8]only to discover that pgp -sa file produced unintellible gibberish, that could only be made sense of by pgp, so that no one would be able to read it without first checking my signature. David Howe you made a minor config error - you need to make sure clearsign is enabled. Not so. It turns out the command line is now different in PGP 6.5.8. It is now pgp -sta to clearsign, instead of pgp -sa. (Needless to say the t option does not appear in pgp -h The clearsigning now seems to work a lot better than I recall the clearsigning working in pgp 2.6.2. They now do some canonicalization, or perhaps they guess lots of variants until one checks out. Perhaps they hid the clear signing because it used not to work, but having fixed it they failed to unhide it? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 1lGJioukjvNCaM/LetfJVNPifdGblhZNTs+GarH2 4RFyr8DSgY3BrltZeP3treEOdb186ZDQzE/S3NYLI
Re: Real-world steganography
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Krumviede wrote: | --On Tuesday, 01 October, 2002 13:54 +1200 Peter Gutmann | | maybe. i'm not sure how many players support it (my spectral D/A | convertor does, but then some of the people at spectral seem to | have invented HDCD). while the CDs i have that use it sound | pretty good, i don't have any good way to compare them when | played back over a non-HDCD capable convertor (i could hook | up one of my computer CD drives, but that doesn't seem fair | compared to the spectral transport-D/A combination). | The extra 4 bits add quite a bit, subjectively. I've compared the same CD on the same system with an HDCD player and non-HDCD player. | but when i do play such CDs on other gear, i don't notice any | audible degradation, so it isn't obviously harmful. | | i've seen comments in reviews of professional CD mastering | gear that there are other, seemingly preferred, technologies, | although i've never found details of them. | The other formats of note are probably SACD and then DVD-Audio. SACD is multichannel 16-bit/44.1kHz... so multichannel CD without additional sample resolution (if I recall). SACD is not backwards compatible though, whereas HDCD is. DVD-Audio is really the way to go, though... 24-bit/96kHz multichannel or up to 192kHz two-channel. Lots more bits, lots more samples. It makes a huge difference on pretty good or better gear. Regards, Jeremey. - -- Jeremey Barrett [[EMAIL PROTECTED]]Key: http://rot26.com/gpg.asc GnuPG fingerprint: 716E C811 C6D9 2B31 685D 008F F715 EB88 52F6 3860 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9mRND9xXriFL2OGARAp52AKCk2otuMwkRyhssJw/RnsinKM2sewCfRlUf /Fz7ezIMUdKAolx/n/Ti89w= =IsJf -END PGP SIGNATURE-
Re: Real-world steganography
The other formats of note are probably SACD and then DVD-Audio. SACD is multichannel 16-bit/44.1kHz... so multichannel CD without additional sample resolution (if I recall). SACD is not backwards compatible though, whereas HDCD is. DVD-Audio is really the way to go, though... 24-bit/96kHz multichannel or up to 192kHz two-channel. Lots more bits, lots more samples. It makes a huge difference on pretty good or better gear. You kinda got it mixed up. SACD (Sponsored by SONY) is actually being targeted for 24/96 (or was that 24/88...I can't remember) for 2-channel audio, while DVD-A (also 24/96, I believe)is being pushed towards multichannel (5+1) audio. Neither will play in a standard DVD player, though some discs will contain a 16/48kHz version for regular DVD players. As for backward compatibility, though, SACD has the capability to contain a CD layer AND an SACD layer, and SONY has announced that they'll be releasing a lot of stuf like this (like the Stones remastered back catalogue, I think). And theoretically, they'll price the discs at under $20 with the idea that non-audiophiles can buy them and play them in a standard CD player now, and then get the high bitrate version when they buy an SACD player one day. DVD-A will always require a special DVD player--there is no CD layer specified (CD and DVD use different lasers and have different pit sizes--they are intrinisically incompatible at the physical layer.) As for steganography, a problem that audiophiles are pointing out is that DVD-A contains some kind of anti-piracy watermarking that degrades the sound as compared to SACD. Meanwhile, the marketing for DVD-A is all confused, so it's likely DVD-A will be DOA in a few years (a lot of folks don't believe there's a market for 5+1 audio anyway). In addition, there are not a lot of 5+1 audio recordings anyone wants to hear, and remixing 2 channels into 5+1 is always a questionable process. From: Jeremey Barrett [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Peter Gutmann [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Real-world steganography Date: Mon, 30 Sep 2002 22:15:21 -0500 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Krumviede wrote: | --On Tuesday, 01 October, 2002 13:54 +1200 Peter Gutmann | | maybe. i'm not sure how many players support it (my spectral D/A | convertor does, but then some of the people at spectral seem to | have invented HDCD). while the CDs i have that use it sound | pretty good, i don't have any good way to compare them when | played back over a non-HDCD capable convertor (i could hook | up one of my computer CD drives, but that doesn't seem fair | compared to the spectral transport-D/A combination). | The extra 4 bits add quite a bit, subjectively. I've compared the same CD on the same system with an HDCD player and non-HDCD player. | but when i do play such CDs on other gear, i don't notice any | audible degradation, so it isn't obviously harmful. | | i've seen comments in reviews of professional CD mastering | gear that there are other, seemingly preferred, technologies, | although i've never found details of them. | The other formats of note are probably SACD and then DVD-Audio. SACD is multichannel 16-bit/44.1kHz... so multichannel CD without additional sample resolution (if I recall). SACD is not backwards compatible though, whereas HDCD is. DVD-Audio is really the way to go, though... 24-bit/96kHz multichannel or up to 192kHz two-channel. Lots more bits, lots more samples. It makes a huge difference on pretty good or better gear. Regards, Jeremey. - -- Jeremey Barrett [[EMAIL PROTECTED]]Key: http://rot26.com/gpg.asc GnuPG fingerprint: 716E C811 C6D9 2B31 685D 008F F715 EB88 52F6 3860 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE9mRND9xXriFL2OGARAp52AKCk2otuMwkRyhssJw/RnsinKM2sewCfRlUf /Fz7ezIMUdKAolx/n/Ti89w= =IsJf -END PGP SIGNATURE- _ Send and receive Hotmail on your mobile device: http://mobile.msn.com
Court rules up-skirt peep cams legal
Court rules up-skirt peep cams legal In a ruling that could change fashions in Washington state, the supreme court there has ruled that up-skirt cams do not violate voyeurism laws. The Washington Supreme Court judges said that two men who took surreptitious photos and video of women and girls using tiny cameras engaged in disgusting and reprehensible behavior. However, the judges said they did not infringe on any reasonable expectations of privacy because the images were captured in public places. http://news.com.com/2100-1023-960151.html [Using almost identical logic cities around the country have passed ordinances prohibiting the wearing of masks. So, by extension, might a city pass an ordinance that prohibits a woman from wearing underwear with a skirt? Enquiring legal minds want to know ;-) steve]
Re: Real-world steganography
At 09:38 PM 09/30/2002 -0700, Bram Cohen wrote: Peter Gutmann wrote: I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. I don't think that's really 'steganography' per se, since no attempt is made to hide the fact that the information is in there. The quasi-stego used is just to prevent bad audio artifacts from happening. Traditional digital telephone signalling uses a robbed-bit method that steals the low-order bit from every sixth voice sample to carry information like whether the line is busy or idle or wants to set up a connection. (That's why you only get 56kbps and not 64kbps in some US formats, since it doesn't want to keep track of which low bits got robbed.) In a sense both of these are steganography, because they're trying to hide the data channel from the audio listener by being low level noise in ways that equipment that isn't looking for it won't notice. That's not really much different from encoding Secret Data in the LSB of uncompressed graphics or audio - it's about the second-crudest form of the stuff, and if you think there are Attackers trying to decide if you're using stego, you need more sophisticated stego - at minimum, encoding the stegotext so it looks like random noise, or encoding the stegotext with statistics resembling the real noise patterns, or whatever. The definition of hidden writing doesn't specify how hard you tried to hide it or how hard the Attacker is looking - you need to Bring Your Own Threat Model. Since I don't speak Audiophile Engineering / Human perceptual modelspeak, which the paper was written in, I wasn't able to figure out where the HDCD stuff hides the extra bits. Are they really there (in the CDROM's error-correction bits or something)? It sounded like they were either saying that they make part-time use of the one LSB bit to somehow encode the LSB and 4 more bits, which sounded really unlikely given that there weren't any equations there about the compression models, or else that they had some perceptual model and were using that to make a better choice of LSB than a simple 50% cut-off of the A-to-D converter (more absolute distortion, but better-sounding distortion.) Or did I miss the implications of the reference to oversampling and the real difference is that HDCD disks really have more pixels on the disk with only the LSB different, so a conventional reader reads it fine but needs the ECC to get the LSB? A separate question is - so is there some internet-accessible list of disks using HDCD, or do I just have to look at the labels for a logo?
RE: What email encryption is actually in use?
Peter wrote [about the benefits of STARTTLS]: As opposed to more conventional encryption, where you're protecting nothing at any point along the chain, because 99.99% of the user base can't/won't use it. In any case most email is point-to-point, which means you are protecting the entire chain (that is, if I send you mail it may go through a few internal machines here or there, but once it hits the WAN it's straight from my gateway to yours). I must concur with Peter. The overwhelming majority of email recipients with whom I routinely exchange PGP encrypted email operates their own MTAs, located within their trust boundaries. Which should come as no surprise, since those with whom I discuss topics requiring secure communications tend to be conscious of security and thus like to be able to control the properties of their MTA and other network services. I also agree that current MTAs' implementations of STARTTLS are only a first step. At least in postfix, the only MTA with which I am sufficiently familiar to form an opinion, it appears impossible to require that certs presented by trusted parties match a particular hash while certs presented by untrusted MTAs can present any certificate they desire to achieve EDH-level security. I am aware that the certs presented by trusted parties could of course all be signed by the same CA, but this is an unworkable model in personal communications. What is required in practice is a list of trusted MTAs with corresponding hashes implemented at the MTA level. --Lucky Green
Re: Real-world steganography
Peter Gutmann wrote: I recently came across a real-world use of steganography which hides extra data in the LSB of CD audio tracks to allow (according to the vendor) the equivalent of 20-bit samples instead of 16-bit and assorted other features. According to the vendors, HDCD has been used in the recording of more than 5,000 CD titles, which include more than 250 Billboard Top 200 recordings and more than 175 GRAMMY nominations, so it's already fairly widely deployed. Yeah, right - and green felt-tip around the edges of your CD improves the sound, too. 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
