October 2002 - cypherpunks-legacy

Re: What email encryption is actually in use?
by pgut001＠cs.auckland.ac.nz 02 Oct '02

02 Oct '02

"David Howe" <DaveHowe(a)gmx.co.uk> writes: >at Tuesday, October 01, 2002 3:08 AM, Peter Gutmann ><pgut001(a)cs.auckland.ac.nz> 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. 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). Peter.

3 2

Sunshine and Mickey!
by michelle7007149＠yahoo.com 02 Oct '02

02 Oct '02

1 0

Re: What email encryption is actually in use?
by David Howe 02 Oct '02

02 Oct '02

-----BEGIN PGP SIGNED MESSAGE----- at Tuesday, October 01, 2002 9:04 PM, Petro <petro(a)bounty.org> was seen to say: > Well, it's a start. Every mail server (except mx1 and > mx2.prserv.net) should use TLS. Its nice in theory, but in practice look how long it takes the bulk of the internet to install urgent patches - how long is it going to take to get people to install an upgrade to privacy that actually causes more problems for them? Besides the core here is that 1) everyone with a server enroute can read the mail 2) you are relying on every other link in the chain to protect your privacy clientside crypto fixes both these problems, reduces the total crypto load on the chain (encryption/decryption is only ever done once) and allows use of digital signatures. > Once you start using it, it becomes part of hte pattern by wich > other people identify you. Exactly the intention, yes :) Just for the sake of it (anyone who cares will have seen my signature enough times by now) I will sign this one :) -----BEGIN PGP SIGNATURE----- Version: PGP - Cyber-Knights Templar iQIVAwUBPZqzpWDKt9Hjj5SVAQFlwA//cQYGFRb3sJEM695lWJ+rUhymcS5lTSEV vG3eRUvxpbhLcAS+QsdMXX3pDlu60UzOhxubpQch9E59yE/+uaeU+5AzkfDQjc2q jQ8SppCqf56+uevoZlH1RiKkBT6Hx7ctPimEIlq3FXWsaqA3ocPVghZwFhMaxA1G twCtBxR7Q3y6VePzCzeealx7TDgcoS7hoBKNTsueAIWd/9xB9JYjFvS8OecOMdZG B+yvSLHZn1YJG62JfZ8EWXr1xKh5BZxdRVxLVzhaumtyAFr2hCDQffDiz5UtyGSa JdMoJAzmZZZ5EvcHc0rMDVs5BiDr5/EaSU+xecPz/YxY4BWxGFprqsRi7IapTkb1 26zgJQ4miGylFlmZM30cxKYudi5PdSJ4VUWpuoHRg9clZlH9KzC7f0suYAnACDXC bzr5Fgp3+bvRnziMD65NT4G1hxA5pYPl+4IudVSKcaMsHLWSTE8Lnf0US283MdeR VXKbINvyEr0p0zrl7lVmHZbmuLjdUHrgAoyQEKcaMelE+Q8suXynDYtSV7LCfdAE CjKBz2RxAiNhi1vAq6NuFOMx+R9c23Sxg2uUUbpYeRbl5fPbjamDzIhK2ccNNmpU euuWj3O9e6YMtW0KPezYbJ/9fMMkOAv3KnfdeAgcjSnipMqVvqgJ4sWil3gfUADY X0TKznTghWs= =3uOF -----END PGP SIGNATURE-----

1 0

Re: What email encryption is actually in use?
by David Howe 02 Oct '02

02 Oct '02

at Tuesday, October 01, 2002 6:10 PM, James A. Donald <jamesd(a)echeque.com> was seen to say: > 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 *nods* its in the 6.5 Command Line Guide, but as "identifies the input file as a text file" The CLG is the best reference for this though - as it explictly lists sta as the correct option in section Ch2>Common PGP Functions>Signing Messages>Sign a plaintext ASCII file. I could email you a copy of the PDF of that (its about 500K) if you wish. > 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. its canonicalization - again according to the CLG (CH3>Sending ASCII text files to different machine environments) > Perhaps they hid the clear signing because it used not to work, > but having fixed it they failed to unhide it? its just an evolution. IIRC the command line tool was based at least partially on the unix version of pgp, which always had different command line switches. It would be nice if behaviour was more backwards compatable, but they *did* document it in the official M that you should RTF :)

1 0

fun w/ the SS & chalk
by Major Variola (ret) 02 Oct '02

02 Oct '02

2 1

Information for cypherpunks@minder.net
by Claud Choi 02 Oct '02

02 Oct '02

1 0

Real-world steganography
by pgut001＠cs.auckland.ac.nz 01 Oct '02

01 Oct '02

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 this system. The most likely result of an error in the signal is a missed command, which can result in a temporary mis- tracking of the decoding, as mentioned above. Given the low density of command data, and the small changes to the signal which the process uses, these errors are seldom more audible than the error would be in the absence of the process. The chances of a storage error being falsely interpreted as a command are extremely small. For material not recorded using the encoder, a small probability for a false trigger does exist. Given a moderate length for the scrambling shift register so that its mapping behaves in a noise-like fashion and a choice of synchronizing pattern which avoids patterns likely to appear in audio data with a higher than average probability, susceptibility to false triggers can be made arbitrarily small by increasing the length of the part of the packet requiring a match. In the case of the current system, the combination of the synchronizing pattern with the bit equivalence for all valid commands plus check sum results in a required match equivalent to 39 sequential bits. For a stereo signal, in which a match must occur in both channels within a one second interval and the commands in both channels must specify the same gains, this amounts to an expectation of one event in approximately 150 million years of audio. The scrambling operation uses a feedback shift register designed for a maximal length sequence in which data taken from taps in the register are added using modulo two arithmetic, equivalent to an 'exclusive or' operation, and fed back to the input of the register. For a given register length there are certain configurations of taps which will produce a sequence of one and zero values at the output that does not repeat until 2N-1 values have emerged, where N is the length of the shift register. This corresponds to the number of possible states of the shift register minus one illegal state, and is called a maximal length sequence. Such an output sequence has very noise-like properties and, in fact, is the basis of some noise generators. We use the noise-like behavior of the generator to scramble the command signals by adding them modulo two to the input of the shift register, as for example in Figure 7a. This has the advantage that a second similar shift register with taps in the same places but with only feed forward addition modulo two (Figure 7b) will reproduce the original input sequence when fed with the output of the first one. The fact that the decode side has no feedback means that the initialization requirements are limited to having N input samples prior to the beginning of decoding, which means that the decoder will "lock up" very quickly. In this scheme, the presence of a bit error anywhere in the length of a packet plus initialization sequence will completely scramble the data, preventing recovery. However, in practice, this has not been a problem for reasons described above. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

8 8

Court rules up-skirt peep cams legal
by Steve Schear 01 Oct '02

01 Oct '02

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]

1 0

journalists as spies
by Major Variola (ret) 01 Oct '02

01 Oct '02

http://www.washtimes.com/upi-breaking/20020930-052952-9407r.htm "I was working with Pearl," said Baer, who has written a book about his time as a CIA official and has acted as a consultant and source for numerous media outlets. "We had a joint project. Mohammed was the story he was working on, not Richard Reid."

1 0

FREE UK SEX SITE
by ianrking＠yahoo.co.uk 01 Oct '02

01 Oct '02

check this out, the best UK FREE sex site, outdoor sex, public sex, beautiful girls, go to http://www.tamara.co.uk

1 0