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: 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
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 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
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
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
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
What email encryption is actually in use?
-- James A. Donald: > > We have tools to construct any certificates we damn well > > please, Joseph Ashwood: > The same applies everywhere, in fact in your beloved Kong, > the situation is worse because the identities can't be > managed. You are unfamiliar with Kong. The situation is better, because it is designed to be used in the fashion that all other existing alternatives actually are used in practice. James A. Donald: > > 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. Joseph Ashwood: > Which would of course demonstrate once more that you have no > clue how to use PGP. It also demonstrates what is probably > your primary source of "I can't decrypt it" you are using a > rather old version of PGP. In fact my version is network associates version 6.5.8, which can supposedly decrypt any valid pgp message, and your rant would be considerably more impressive if you signed your message with a PGP signature. Doubtless you could sign it -- eventually, after a bit of trying, after you had spent about as much time farting around as I did. The proclamation that PGP is usable would have been much more impressive in a message that actually used it. James A. Donald: > > 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. You are full of shit. 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 the net. If you say it is broken, break it! --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG nfNdl11zVV+oWKMTt0l79zrcrelHalABSBwKeib2 4Ts9fALHrytq8hR6Dhue492m/1vO+fYHy4Kqa6dkQ
Hackers make Xbox into a Windows PC
Hackers make Xbox into a Windows PC The Xbox has been made to run Microsoft's own operating system, turning it into an ordinary desktop workstation, courtesy of some Linux trickery. The accomplishment is a comment on the insecurity of secure hardware http://news.zdnet.co.uk/story/0,,t269-s2123049,00.html
Re: What email encryption is actually in use?
> What email encryption is actually in use? PGP 2.6.*, 6.* & 7.* work like a charm across macs & windoze & unices provided that one specs RSA-legacy keys and limit algo to IDEA. In other words, be 2.6.2 compatible. If you need encryption, that is. If you don't need encryption (like in They Will Not Come After You If They Read Your E-mail) then feel free to bitch about interfaces and inconveniances. If you're just bored and like to speculate and fix unbroken stuff, I suggest one time pads distributed via $40 64 MByte USB flash drives - everything fits there, including your mail client, your OTP interface and enough key material to last lifetime for things you can type. In other words, those that need crypto are taken care of, and in order to gain resources to make sheeple use crypto you have to become Them, in which case you don't really want sheeple to use crypto in the first place. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com
Re: What email encryption is actually in use?
- Original Message - From: "James A. Donald" <[EMAIL PROTECTED]> > What email encryption is actually in use? In my experience PGP is the most used. > When I get a PGP encrypted message, I usually cannot read it -- > it is sent to my dud key or something somehow goes wrong. Then you are obviously using PGP wrong. When you choose your 768-bit key in 1996 (I checked the key servers) you should have considered the actual lifetime that the key was going to have. In 1996 a 768-bit key was considered borderline secure, and it was just about time to retire them. Instead of looking at this and setting an expiration date on your key, you instead choose to make it live forever. Your other alternative would have been to revoke that key before you retired it. You made critical mistakes, and you blame it on PGP. As to it's dependability. I've seen two problems when someone could not decrypt the PGP message; 1) They shouldn't have access to it (someone elses key, forgot passphrase, etc), 2) They didn't have any clue how to use PGP, these people generally have trouble turning on their computer. On rare occassions there will be issues with versions, but in my experience these are exceptionally rare. > Kong encrypted messages usually > work, because there is only one version of the program, and key > management is damn near non existent by design, since my > experience as key manager for various companies shows that in > practice keys just do not get managed. After I release the next > upgrade, doubtless fewer messages will work. Maybe you should have considered designing the system so that it could be upgraded. A properly designed system can detect when an incompatible version was used for encryption, and can inform the user of the problem. Additionally I think there is one core reason why Kong decryptions always work, no one uses it, without key management it is basically worthless. Fortunately because there is no userbase you can change it dramatically for the next release, maybe this time it'll be worth using. > The most widely deployed encryption is of course that which is > in outlook -- which we now know to be broken, since > impersonation is trivial, making it fortunate that seemingly no > one uses it. If you did some research, you'd find that it is called S/MIME, it is a standard, a broken standard, but a standard (admittedly Outlook implemented it poorly and that is a major source of the breakage). The only non-standard encryption outlook uses is in the file storage, which has nothing to do with email. > Repeating the question, so that it does not get lost in the > rant. 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? The two big players are PGP and S/MIME. > > The chief barrier to use of outlook's email encryption, aside > from the fact that is broken, is the intolerable cost and > inconvenience of certificate management. Actually the chief barrier is psychological, people don't feel they should side with the criminals by using encryption. Certificate management is actually quite easy and cheap. It is the mistakes of people who lack any understanding of how the system actually works that make it expensive and inconvenient. The same applies to PGP. > We have tools to > construct any certificates we damn well please, The same applies everywhere, in fact in your beloved Kong, the situation is worse because the identities can't be managed. > though the root > signatures will not be recognized unless the user chooses to > put them in. That's right, blame your own inadequacies on everyone else, that seems to be the standard American way now. > 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 it is, in fact there are about 140 root certificates that Internet Explorer recognises, the majority of these have absolutely nothing to do with Verisign. Getting it into the systems is a big more problematic. > (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.) And this has nothing whatsoever to do with root certificates. > 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. Which would of course demonstrate once more that you have no clue how to use PGP. It also demonstrates what is probably your primary source of "I can't decrypt it" you are using a rather old version of PGP. While the rest of the world has updated PGP to try to remain secure, you have managed to
Re: What email encryption is actually in use?
On Mon, Sep 30, 2002 at 12:53:36PM -0700, Joseph Ashwood wrote: > - Original Message - > From: "James A. Donald" <[EMAIL PROTECTED]> > > The chief barrier to use of outlook's email encryption, aside > > from the fact that is broken, is the intolerable cost and > > inconvenience of certificate management. > Actually the chief barrier is psychological, people don't feel they should > side with the criminals by using encryption. Certificate management is Um. No. Most people do no assocaite encryption with criminals. There are 4 reasons people don't use encryption in email: 0) "Encryption, that's that SLS thingy, right?" (Ignorance, stupidity) 1) Why bother? I am not a *target*. (apathy) 2) It's too much hassle. (BAD tools) 3) 95% of the people *I* send email to wouldn't know what to do with a message in S/MIME, much less PGP. (AKA the Fax Effect). -- Johnny had four truckloads of plutonium. Johnny used four| Quit smoking: truckloads of plutonium to light New York City for a year. | 161d, 11h ago Then how many truckloads of plutonium did Johnny have? Six! | petro@ -- Breeder reactor ad from the glory days of nuclear power | bounty.org
Re: Anyone can get a clearance these days...
At 09:38 AM 09/27/2002 -0400, Adam Shostack wrote: >"The US Government has mistakenly given secret documents to the only >man charged so far in connection with the 11 September attacks, >Zacarias Moussaoui." > >http://news.bbc.co.uk/2/hi/americas/2284325.stm That wasn't because they gave him a security clearance - that was because, as the defendant in a trial, he has the legal right to see the evidence against him, and some of that evidence is classified. Apparently they have some sort of deal where he's not allowed to see the evidence himself, but his court-appointed lawyers are, which is still Constitutionally bogus, but they'd slipped up in the implementation.
Re: smartcards
Quoting James A. Donald ([EMAIL PROTECTED]): > -- > James A. Donald: > > > When Chaumian money comes into wide use, I think that for > > > most end users we will have to stash all unused tokens > > > inside smartcards. > > Someone: > > Here in Hong Kong, contactless "Octopus" smartcards (based on > > the Sony FeliCa device) are well established for paying fares > > on buses, ferries and subways, and also for small > > transactions with vending machines, convenience stores and > > supermarkets. > > Critical mass is no problem if a payment mechanism is backed by > the big boys, but the big boys want a mechanism for > transferring value where only a few giant corporations who are > in bed with the state receive transaction payments, a system > that divides the economy into a tiny number of actors, the big > corporations, who alone take action, plan and produce, and huge > number of passive consumer zombies. > > We would like a system which treats those making and receiving > payments as peers, which makes critical mass a considerably > more difficult problem. I'm surprised that nobody has mentioned cell-phones as a digital cash platform. Perhaps this belabours the obvious, but I'll spell it out anyways: o They are ubiquitous. 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? o Peer-to-peer transactions will obviously work via IR. Central clearing mechanisms will work through the phone net. Thus they embody the basic infrastructure for both worlds. The entire thing could be done over SMS, of course, but IR for peer-to-peer, day-to-day transactions is best from a privacy and usability standpoint. o PC-based software is in use for the synchronisation of calendar data, etc. Many people are already familiar with using their phones for these kinds of purposes so what's one more application to the user? The problem is that phone software is (to my knowledge) all closed-source and running on proprietary hardware. What's the liklihood of manufacturers opening up their phones for third-party code? A Java VM might do it, as might something lean like an Inferno VM. More informed list members could probably suggest other virtual machines which would suit our purposes. This would, of course, bring about Black Net rather quickly. I confess that I'm not all that enamoured with the idea, personally, but something like it is already possible with various creative accounting practices so the only real objection can be made by those few who require centralised clearing to preserve their empires. Such intersts will lobby hard to make sure that the only option we have is to route our payments through their systems (without regard to platform). Nonetheless, I'd say that leveraging the cellular phone network and hand-held phones for digital cash systems cover both the usability issues and the critical mass problems thouroughly. All we need to know is who we have to convince in order to get an open, standardised environment and API with math, communications, and crypto libraries for our phones. (Actually, it would be really neat to have cell phones wide-open to user supplied code, but that is probably asking too much.) Regards, Steve
What email encryption is actually in use?
-- What email encryption is actually in use? When I get a PGP encrypted message, I usually cannot read it -- it is sent to my dud key or something somehow goes wrong. When I send a PGP encrypted message in reply, stating the problem, I seldom receive an answer, suggesting that the recipient cannot decrypt my message either. Kong encrypted messages usually work, because there is only one version of the program, and key management is damn near non existent by design, since my experience as key manager for various companies shows that in practice keys just do not get managed. After I release the next upgrade, doubtless fewer messages will work. The most widely deployed encryption is of course that which is in outlook -- which we now know to be broken, since impersonation is trivial, making it fortunate that seemingly no one uses it. Repeating the question, so that it does not get lost in the rant. 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? The chief barrier to use of outlook's email encryption, aside from the fact that is broken, is the intolerable cost and inconvenience of certificate management. We have tools to construct any certificates we damn well please, though the root signatures will not be recognized unless the user chooses to put them in. 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.) 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. 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. Presumably the theory underlying this brilliant design decision was that in the bad old days, a file produced under unix woudl 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. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG OmUO5eB/pLnuFIgCU2splCvKO4x0U1Ik31pVFPaU 49B5UrVKc5ETzoxGcfl+q9ltoh61l4ncSyE+R5h6P
RE: smartcards
> Steve Thompson[SMTP:[EMAIL PROTECTED]] wrote: > > I'm surprised that nobody has mentioned cell-phones as a digital cash > platform. > Perhaps this belabours the obvious, but I'll spell it out anyways: > > o They are ubiquitous. > > 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? > > o Peer-to-peer transactions will obviously work via IR. Central > clearing > mechanisms will work through the phone net. Thus they embody the > basic > infrastructure for both worlds. The entire thing could be done over > SMS, > of course, but IR for peer-to-peer, day-to-day transactions is best > from a > privacy and usability standpoint. > > o PC-based software is in use for the synchronisation of calendar data, > etc. > Many people are already familiar with using their phones for these > kinds > of purposes so what's one more application to the user? > > The problem is that phone software is (to my knowledge) all closed-source > and > running on proprietary hardware. What's the liklihood of manufacturers > opening up their phones for third-party code? A Java VM might do it, as > might > something lean like an Inferno VM. More informed list members could > probably > suggest other virtual machines which would suit our purposes. > [...] > Regards, > Steve > 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). 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. Peter Trei
Re: smartcards
-- On 30 Jan 2050 at 32:210, Steve Thompson wrote: > I'm surprised that nobody has mentioned cell-phones as a > digital cash platform.[] > > The problem is that phone software is (to my knowledge) all > closed-source and running on proprietary hardware. What's > the liklihood of manufacturers opening up their phones for > third-party code? An open platform would be a combined cell phone and palm top computer. Lots of people are trying to move this -- so far without wide acceptance. Paypal's original vision was that people would use palm pilots with IR. If phones developed palm pilot capabilities, this vision would become more useful. I think combining the palm pilot with the cell phone is more feasible once we develop a good voice controlled computer, after the fashion of startrek, which may be some time off. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG z0mctqiLain3vlXnFZTOy5PEVJIwCeg0x7zxl4RQ 4DWhd8THkIxyeHtI7sSA5O1d9IKi7WwGZVh6roOOb
Re: Random Privacy
This is an old statistical technique. You need to know ahead of time which answer is more likely and have a bias in your randomizer. A classic example: Did you cheat on your wife last year? If you were born between January and September reverse your answer. -- Julian Assange|If you want to build a ship, don't drum up people |together to collect wood or assign them tasks and [EMAIL PROTECTED] |work, but rather teach them to long for the endless [EMAIL PROTECTED] |immensity of the sea. -- Antoine de Saint Exupery
Austin Cpunks - Oct. 10 Physical Meeting
Time:Oct. 10, 2002 Second Tuesday of each month 7:00 - 9:00 pm (or later) Location:Central Market HEB Cafe 38th and N. Lamar Weather permitting we meet in the un-covered tables. If it's inclimate but not overly cold we meet in the outside covered section. Otherwise look for us inside the building proper. Identification: Look for the group with the "Applied Cryptography" book. It will have a red cover and is about 2 in. thick. Contact Info:http://einstein.ssz.com/cdr/index.html#austincpunks -- We don't see things as they are, [EMAIL PROTECTED] we see them as we are. www.ssz.com [EMAIL PROTECTED] Anais Nin www.open-forge.org
