Re: Yahoo releases internet standard draft for using DNS as public key server

[Dave Howe]

Ian Grigg wrote:
Dave Howe wrote:
No - it means you might want to consider a system that guarantees 
end-to-end encryption - not just "first link, then maybe if it feels 
like it"
That doesn't mean TLS is worthless - on the contrary, it adds an 
additional layer of both user authentication and session encryption 
that are both beneficial - but that *relying* on it to protect your 
messages is overoptimistic at best, dangerous at worst.
This I believe is a bad way to start looking
at cryptography.  There is no system that you
can put in place that you can *rely* upon to
protect your message.
No, there are plenty that you can rely on to protect your message while 
still in transit.
If you can ensure that the only possible points of vulnerability are at 
the two endpoints, then you and your correspondent take control of your 
security - it won't be perfect, as you point out - but you won't be 
reliant on the goodwill and efforts of some third party whose most 
economic option is to accidentally or deliberately neglect TLS between 
your local smart host and your correspondent's email spooler, or indeed, 
to supply minimal security to the email spools at smarthost or destination.

(Adi Shamir again: #1 there are no secure systems,
ergo, it is not possible to rely on them, and
to think about relying will take one down false
paths.)
Secure systems exist - but are rarely worth the effort involved.
Many PDAs can handle PGP or S/Mime traffic these days - certainly, you 
could offload your message (already encrypted) to flash media, insert 
into sending host, receive (from email spool) at the destination and 
transfer to flash media, then insert into decoding PDA.  To compromise 
either PDA would require access - so if you keep it about your person 
(and within sight when you bathe), you should be safe against anything 
but a midnight intrusion with sleeping gas
But regardless - the level of defence required is proportional to the 
likely threat.  It is entirely possible that it would be worthwhile for 
some hacker to compromise a router between your ISP's mail server and 
your correspondent's spool, or that spool itself. It is less likely that 
it would be worth someone's while to break into your home with exquisite 
timing and tracelessly alter software on your trusted airgapped machine 
while you shower (and if that *is* your threat model, I envy the income 
you must get to justify being in such a position or bow to the value of 
your information to some repressive regime)

Otherwise, we adopt what military people call
"tactical security:"  strong enough to keep
the message secure enough so that most of the
time it does the job.
Indeed so.
The principle which needs to be hammered time
and time again is that cryptography, like all
other security systems, should be about risk
and return - do what you can and put up with
the things you can't.
Again, true. I suspect we differ in what we consider an acceptable risk 
- I don't consider any setup where the security of the channel is 
against the best interests of the people controlling that channel 
acceptable - especially where I have no way to discover if that channel 
was compromised.
I have what I hope is an acceptably secure system at home - and I also 
hope my correspondents do likewise. If our messages are compromised (not 
that they contain anything worth stealing) then it is my fault or theirs 
- not an admin at the isp, or some minimum-wage employee on a helpdesk 
bribed to let someone take a peak at my mailspool. This extra security 
comes free, gratis, not a penny does it cost - beyond the effort of 
learning how to use it - and while I was used to hotkeying my way into 
the current window, my recent switch to Enigmail means I don't even have 
to do that. Why would I settle for less?

Applying the specifics to things like TLS and
mail delivery - yes, it looks very ropey.  Why
for example people think that they need CA-signed
certs for such a thing when (as you point out)
the mail is probably totally unprotected for half
the journey is just totally mysterious.
And indeed I had a conversation with someone who was interested in a 
"secure" mailing list only a few days ago. I suggested he not bother and 
 just set up a HTTPS website with any one of a dozen BBoard systems and 
local certificate support - because that was free and all the complexity 
(and most of the vulnerabilites) are at the server side - while setting 
up a secure email burster would be almost impossible and would rely on 
not only training the end users, but ensuring they have the right 
software installed.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Anne & Lynn Wheeler]

At 10:14 PM 5/30/2004, Peter Gutmann wrote:
The S/MIME list debated this some time ago, and decided (pretty much
unanimously) against it, for two reasosn.  Firstly, because it adds huge ugly
blobs of base64 crap to each message (and before the ECC fans leap in here,
that still adds small ugly blobs of base64 crap to each message).  Secondly,
because if you get a message from someone you know you'll be able to get a
pretty good idea of its authenticity from the content (for example an SSH
developer would be unlikely to be advocating SSL in a list posting), and if
you get a message from someone you don't know then it's pretty much irrelevant
whether it's signed or not.  So the consensus was not to sign messages.

this may or may not be my KISS authentication thread.
mid-90s, some number of financial institutions retrenched from x.509 
identity certificates to simple relying-party-only certificates ... because 
of enormous privacy issues regarding blanketing the world with privacy 
information contained in identity certificates.

however, they were still looking at taking a 60-80 bytes payment message, 
attaching a 128byte digital signature, and then attaching a 4k byte to 12k 
byte relying-party-only certificate ... and sending it back to the 
financial institution that issued the certificate. this is not counting any 
ASN.1 encoding that might have been done which then possiby includes a 
bunch more bytes. note that standard payment message message has been 
around some 30 years carefully crafted as simple 7bit ascii w/o any 
addition encoding requirements. the purpose of the certificate was to carry 
the account number ... which was also included in the signed payment 
message ... and the public key ... which was stored in the account record 
back at the financial institution that was receiving the transmission and 
had originally issued the relying-party-only certificate.

so the financial institution receives this new payment object, retrieves 
the account number from the (signed) payment message and uses the public 
key in the account record to verify the signature ... w/o ever resorting to 
the certificate. So we have a payload bloat of one hundred times ... in 
order to carry a certificate that is redundant and superfluous and never used.

so x9.59 was fairly carefully crafted to add a 42byte ECC signature to a 
standard 60-80byte payment message. any special encoding to carry 42byte 
ecc 8bit in 7bit transmission at worst doubled the signature payload size.
http://www.garlic.com/~lynn/index.html#x959

--
Anne & Lynn Wheelerhttp://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: The future of security

[Eugen Leitl]

On Mon, May 31, 2004 at 08:27:49PM -0700, bear wrote:

> >The point of an automated web of trust is that the machine is doing the
> >accounting for you.
> 
> Does it?  If there were meaningful reputation accounting

You got fooled by the present tense. If there was such an architecture, I
wouldn't have written that message. The distributed tamper-proof
cryptographic p2p store should have been a dead giveaway.

> happening, we'd be getting feedback and value judgements
> from the system on the people we were corresponding with.
> Have you ever seen any?

No, of course. See above.
 
> Has there been *ANY* instance of negative consequences
> accruing to someone who signed the key of an entity which
> later defected?  Machine-moderated or not, the web of
> trust fails.

The web of trust sure fails, dunno about machine-moderated. 
There's no such animal yet.
 
> Have you seen any web-of-trust implementation that even
> *considers* the trustworthiness of the key servers?  Have
> you seen any web-of-trust implementation that works to
> cut out defectors, but couldn't be "autospammed" to cut
> out anyone you didn't like?

If you don't have their key, you can't pretend to sign the spambots'. If you
sign the spambots', you burn whatever little prestige you have happened to
start out with, and drained the mana of whatever hapless warm body signed
your keys.
 
> Sorry; but the fact is no web-of-trust implementation to
> date works, or even comes close to working.

Web of trust is useless, if Johnny User is supposed to do 
the checking.

-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07078, 11.61144http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE
http://moleculardevices.org http://nanomachines.net


pgpPzt821GHi8.pgp
Description: PGP signature

Re: Software Helps Rights Groups Protect Sensitive Information

[Mark Armbrust]

At 16:08 2004-05-31 -0400, Ivan Krstic <[EMAIL PROTECTED]> wrote:
>This reminds me of a question I've been meaning to ask for a while. Has 
>there been any research done on encryption systems which encrypt two (or 
>n) plaintexts with n keys, producing a joint ciphertext with the 
>property that decrypting it with key k[n] only produces the nth plaintext?
>
>In the particular scenario that the article describes, activists need to 
>protect their information from people that probably have little respect 
>for the Geneva convention and would possibly find any evidence of 
>encrypted information as proof enough that there is illegal activity 
>going on. This, in turn, might lead to the police beating the key out of 
>them.
>
>Now, if a solution such as Apple's FileVault or PGP's PGPDrive offered 
>an "interleaved drive" system where one file stored multiple encrypted 
>disks, and which one is accessed depended on which key you provided, 
>perhaps things can be changed a bit. Password A unlocks a drive with 
>mild dissidence information to appear credible. Password B unlocks a 
>drive with the truly secret data. If captured, after some hours of a 
>(probably highly unpleasant) interrogation, the dissident gives password 
>A, interrogators try it, it works, they find nothing of tremendous use 
>and dissident walks.

BestCrypt (http://www.jetico.com/) claims to do this for N = 2:
  "BestCrypt v.7 also allows the creation of hidden containers -
  containers not evident to an intruder. You can simply create
  another (hidden) container inside already existing (shell)
  container. Data stored inside shell and hidden containers
  can be completely different, passwords for the containers
  are also different, and it is not possible to determine
  whether the shell container has a hidden container inside
  it, or not. Version 7 help documentation contains detailed
  information on the creation and management of hidden
  containers."

--Mark

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Ian Grigg]

Dave Howe wrote:
Ian Grigg wrote:
 Dave Howe wrote:
> TLS for SMTP is a nice, efficient way to encrypt the channel.
> However, it offers little or no assurance that your mail will
> *stay* encrypted all the way to the recipients.
 That's correct. But, the goal is not to secure email to the extent
 that there is no risk, that's impossible, and arguing that the
 existence of a weakness means you shouldn't do it just means that we
 should never use crypto at all.
No - it means you might want to consider a system that guarantees 
end-to-end encryption - not just "first link, then maybe if it feels 
like it"
That doesn't mean TLS is worthless - on the contrary, it adds an 
additional layer of both user authentication and session encryption that 
are both beneficial - but that *relying* on it to protect your messages 
is overoptimistic at best, dangerous at worst.

This I believe is a bad way to start looking
at cryptography.  There is no system that you
can put in place that you can *rely* upon to
protect your message.
(Adi Shamir again: #1 there are no secure systems,
ergo, it is not possible to rely on them, and
to think about relying will take one down false
paths.)
In general terms, most ordinary users cannot
rely on their platform to be secure.  Even in
specific terms, those of us running BSD systems
on laptops that we have with us all the time
still have to sleep and shower...  There are
people out there who have the technology to
defeat my house alarm, install a custom
key logger designed for my model of laptop,
and get out before the hot water runs out.
For that reason, I and just about everyone
else do not *rely* on tech to keep my message
safe.  If I need to really rely on it, I do what
Adolf Hitler did in November of 1944 - deliver
all the orders for the great breakout by secure
courier, because he suspected the enigma codes
were being read.  (He was right.)
Otherwise, we adopt what military people call
"tactical security:"  strong enough to keep
the message secure enough so that most of the
time it does the job.
The principle which needs to be hammered time
and time again is that cryptography, like all
other security systems, should be about risk
and return - do what you can and put up with
the things you can't.
Applying the specifics to things like TLS and
mail delivery - yes, it looks very ropey.  Why
for example people think that they need CA-signed
certs for such a thing when (as you point out)
the mail is probably totally unprotected for half
the journey is just totally mysterious.
iang
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Dave Howe]

Ian Grigg wrote:
 Dave Howe wrote:
> TLS for SMTP is a nice, efficient way to encrypt the channel.
> However, it offers little or no assurance that your mail will
> *stay* encrypted all the way to the recipients.
 That's correct. But, the goal is not to secure email to the extent
 that there is no risk, that's impossible, and arguing that the
 existence of a weakness means you shouldn't do it just means that we
 should never use crypto at all.
No - it means you might want to consider a system that guarantees 
end-to-end encryption - not just "first link, then maybe if it feels 
like it"
That doesn't mean TLS is worthless - on the contrary, it adds an 
additional layer of both user authentication and session encryption that 
are both beneficial - but that *relying* on it to protect your messages 
is overoptimistic at best, dangerous at worst.
In limited circumstances it could well be enough - say, if your 
mailserver *is* yours, and hands off directly to the recipient's mail 
server which you know is accessed by either ssl-secured pop3, https, or 
some other secure access method (or unencrypted, but via a local lan 
link of course) - but for the majority of users this isn't going to be 
possible; more and more ISPs frown on even their business customers 
using direct outbound SMTP, and few sites are willing or able to accept 
mail using the alternate port for TLS.

 The goal is to make it more difficult, within a tight budget. Using
 TLS for SMTP is free. Why not do it?
You should do it - but you shouldn't expect it to do any good; in the 
long term, pushing for TLS support from your ISP, giving them grief 
(within limits of course) to ensure opportunistic TLS outbound, and so 
forth, will increase the security of the system as a whole. but at the 
moment reliance is a step too far.

 a) Once a bunch of people send mail via TLS/SMTP, the ISP is
 incentivised to look at onward forwarding it that way.
Many ISPs accept TLS inbound, but don't specify it outbound. there is no 
value to them in doing so - its transparent to the user either way, adds 
additional load to the local server, and the occasions they get asked 
about it are so rare they can safely ignore it.

 b) It may be that your local threat is the biggest, if for example
 you are using 802.11b to send your mail. The threat of listening
 from the ISP onwards is relatively small compared to what goes on
 closer to the end nodes.
Certainly possible - but of course that implies using SSL during the 
collection too.

 c) every node that starts protecting traffic this way helps - because
 it boxes the attacker into narrower and narrower attacks. It may be
 that the emails are totally open over the backbone, but who cares if
 the attacker can't easily get there?
Indeed so, yes. however, as I say - just because it is a step forward 
towards a completely end-to-end secure link, it is worth doing - even a 
little extra security for free is worth having - but if it is important 
enough to *need* encryption, it is important enough to ensure end-to-end 
encryption is used.

I must admit to being impressed by how functional EnigMime for 
thunderbird is in this regard - I can specify per-destination-user that 
encryption will aways be used, and its type - and have it "just work"

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

RE: Software Helps Rights Groups Protect Sensitive Information

[Ian Brown]

>This reminds me of a question I've been meaning to ask for a while. Has

>there been any research done on encryption systems which encrypt two
(or 
>n) plaintexts with n keys, producing a joint ciphertext with the 
>property that decrypting it with key k[n] only produces the 
>nth plaintext?

See the Steganographic File System:
http://www.mcdonald.org.uk/StegFS/


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Ian Grigg]

Dave Howe wrote:
Peter Gutmann wrote:
It *is* happening, only it's now called STARTTLS (and if certain vendors
(Micromumblemumble) didn't make it such a pain to set up certs for 
their MTAs
but simply generated self-signed certs on install and turned it on by 
default,
it'd be happening even more).
TLS for SMTP is a nice, efficient way to encrypt the channel. However, 
it offers little or no assurance that your mail will *stay* encrypted 
all the way to the recipients.

That's correct.  But, the goal is not to secure
email to the extent that there is no risk, that's
impossible, and arguing that the existence of a
weakness means you shouldn't do it just means that
we should never use crypto at all.
See those slides that Adi Shamir put up, I collected
the 3 useful ones in a recent blog:
http://www.financialcryptography.com/mt/archives/000147.html
I'd print these three out and post them on the wall,
if I had a printer!
The goal is to make it more difficult, within a
tight budget.  Using TLS for SMTP is free.  Why
not do it?
(Well, it's free if self-signed certs are used.
If CA-signed certs are used, I agree, that exceeds
the likely benefit.)

Most of us (including me most of the time) are in the position of using 
their ISPs or Employer's smarthost to relay email to its final 
destination; in fact, most employers (and many ISPs) actually enforce 
this, redirecting or blocking port 25 traffic.
If my employer or isp accept TLS traffic from me, but then turn around 
and send that completely unprotected to my final recipient, I have no 
way of preventing or even knowing that.
Sendmail's documentation certainly used to warn this was the case - 
probably still does :)

a) Once a bunch of people send mail via TLS/SMTP,
the ISP is incentivised to look at onward forwarding
it that way.
b) It may be that your local threat is the biggest,
if for example you are using 802.11b to send your
mail.  The threat of listening from the ISP onwards
is relatively small compared to what goes on closer
to the end nodes.
c) every node that starts protecting traffic this
way helps - because it boxes the attacker into
narrower and narrower attacks.  It may be that the
emails are totally open over the backbone, but who
cares if the attacker can't easily get there?
iang
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Colossus reconstruction at Bletchley Park is finished.

[Perry E. Metzger]

(I had the privilege, along with a few other folks on this list, of
seeing the reconstructed Colossus a couple of years ago up close while
it was in an earlier phase of the work. The fact that the job is
now finished is quite cool.)

Return of Colossus marks D-Day
By Jo Twist
BBC News Online technology staff

Colossus Mk2, a wartime code-breaker hailed as one of the first
electronic computers, has been rebuilt and reunited with Bletchley
Park veterans.

http://news.bbc.co.uk/1/hi/technology/3754887.stm

-- 
Perry E. Metzger[EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: A National ID

[Peter Clay]

On Mon, 31 May 2004, R. A. Hettinga wrote:

> in most European countries, people carry national ID's as a matter of
> course. And pressure is mounting in America for some kind of security card.

Similarly, there is a push for ID cards in the UK at the moment. See
http://www.stand.org.uk/ and http://www.no2id.net/ for more detail. No
doubt the same arguments for and against apply on both sides of the
Atlantic, and it would be good if activists were to share information.

Note that the real danger is not the cards but the database for which they
are a unique key. See just about every issue of RISKS for ways in which
big national databases can go wrong.

Pete
-- 
Peter Clay | Campaign for   _  _| .__
   | Digital   /  / | |
   | Rights!   \_ \_| |
   | http://www.ukcdr.org

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Library talk on cryptography begins technology series

[R. A. Hettinga]

NEWS SEARCH


The Princeton Packet

 Library talk on cryptography begins technology series

  By: Jennifer Potash  ,  Staff Writer
 06/01/2004

 Expert promises a nontechnical approach.

No decoder rings are needed for an upcoming talk about the science of
computer cryptography at the Princeton Public Library, but curious minds
will be welcome.
The library kicks off the summer series of its popular Tuesday
Technology Talks program at 7 p.m. today with a lecture by Brian Kernighan,
a professor at Princeton University's Computer Science Department.
Mr. Kernighan, who often gives talks for nontechnical audiences, will
lead an examination of how modern cryptography works, where it is used,
some of the places where it hasn't worked well and a bit of cryptopolitics.
Janie Herman, a reference librarian and founder of the series, said
cryptography has come a long way since the days when Julius Caesar encoded
messages by shifting the alphabet over a few places and when the British
decoded the German Enigma machine during World War II.
"Today, cryptography is at the heart of security for our computers at
home and at work," she said. "It lets us buy and sell securely over the
Internet and it's relied on by both the good guys and bad guys to keep
their secrets safe."
Ms. Herman said she's thrilled to have a speaker of Dr. Kernighan's
stature as a guest for the series - he played key roles in the development
of the Unix and C computer languages, and authored numerous books about
programming in various computer languages.
But don't call him an expert on cryptography - he claims to cringe when
he saw that word used in another article promoting his library talk.
"My interest in cryptography is more of a dilettante interest," he said
with a laugh.
His talk, stripped of the jargon and tech speak found in his classroom
lectures, will be split between a historical perspective on the
cryptography used by the Romans on clay tablets to the codes used by spies
in World War II and ending with the modern uses.
Basically, the difference between cryptography then and now is the size
of the numbers used for the encoding - in the premedieval days cryptography
might be more a matter of shifting letters around while today the numbers
are big, but not infinitely so, Dr. Kernighan said.
The mathematics used in the encoding process were developed back in the
18th century and largely remain unchanged today, he said.
Cryptography works by arranging information in a series of coded
numbers accessible only to users with the correct key, he said.
In practical terms, a user typing in a credit card number to make a
purchase at an online business would have the sensitive information encoded
to keep it safe from any unauthorized users, he said.
While the early days of Internet sales brought tales of thefts of
customers' credit card numbers, today the enterprise is much safer, Dr.
Kernighan said. The problems with credit card number theft are more of a
bricks-and-mortar problem.
"It's like sending your credit card number in an armored truck to a
cardboard box," he said.
Cryptography has also turned up in popular culture such as the Matrix
movies and the best selling novel "The Da Vinci Code."
The novel didn't appeal to Dr. Kernighan. "I thought the writing was
horrible," he said. Also, the study of smaller codes based on letters is
really not what he researches.
Dr. Kernighan, who received his doctorate from Princeton University in
1969, worked for Bell Labs in the computing science research center in
Murray Hill until 2000.
After a few stints as an adjunct professor at Princeton and Harvard
universities, Dr. Kernighan decided to take up teaching full time.
"It's a great place to have a second childhood," said Dr. Kernighan,
who resides in Princeton Borough with his wife.
Princeton Public Library is at 65 Witherspoon St. in Princeton Borough.
Special assistance is available for library customers with disabilities.
Those with special needs should contact the library 48 hours before any
program to arrange for accommodations. Call (609) 924-9529.

-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
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: The future of security

[bear]

On Mon, 31 May 2004, Eugen Leitl wrote:

>> The bigger problem is that webs of trust don't work.
>> They're a fine idea, but the fact is that nobody keeps
>> track of the individual trust relationships or who signed
>
>The point of an automated web of trust is that the machine is doing the
>accounting for you.

Does it?  If there were meaningful reputation accounting
happening, we'd be getting feedback and value judgements
from the system on the people we were corresponding with.
Have you ever seen any?

Has there been *ANY* instance of negative consequences
accruing to someone who signed the key of an entity which
later defected?  Machine-moderated or not, the web of
trust fails.

Have you seen any web-of-trust implementation that even
*considers* the trustworthiness of the key servers?  Have
you seen any web-of-trust implementation that works to
cut out defectors, but couldn't be "autospammed" to cut
out anyone you didn't like?

Sorry; but the fact is no web-of-trust implementation to
date works, or even comes close to working.

Bear

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Software Helps Rights Groups Protect Sensitive Information

[Ivan Krstic]

This reminds me of a question I've been meaning to ask for a while. Has 
there been any research done on encryption systems which encrypt two (or 
n) plaintexts with n keys, producing a joint ciphertext with the 
property that decrypting it with key k[n] only produces the nth plaintext?

In the particular scenario that the article describes, activists need to 
protect their information from people that probably have little respect 
for the Geneva convention and would possibly find any evidence of 
encrypted information as proof enough that there is illegal activity 
going on. This, in turn, might lead to the police beating the key out of 
them.

Now, if a solution such as Apple's FileVault or PGP's PGPDrive offered 
an "interleaved drive" system where one file stored multiple encrypted 
disks, and which one is accessed depended on which key you provided, 
perhaps things can be changed a bit. Password A unlocks a drive with 
mild dissidence information to appear credible. Password B unlocks a 
drive with the truly secret data. If captured, after some hours of a 
(probably highly unpleasant) interrogation, the dissident gives password 
A, interrogators try it, it works, they find nothing of tremendous use 
and dissident walks.

If people have written on this before, I'd appreciate a few references.
As for Zimmerman's comment about keyloggers - I'd hope the software 
offered a point-and-click method of entering the password. This can 
still be defeated with a custom-tailored piece of spyware, but it can be 
made much more difficult for the attackers to do so (depending on how 
well it's coded, it might actually require TEMPEST or the breaking of 
kneecaps to extract the password).

Cheers,
Ivan.
R. A. Hettinga wrote:
SOFTWARE HELPS RIGHTS GROUPS PROTECT SENSITIVE INFORMATION
[snip]
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Software Helps Rights Groups Protect Sensitive Information

[Dave Howe]

R. A. Hettinga wrote:
To prevent loss or theft, the data is backed up automatically and
redundantly on dedicated Martus servers in Manila, Toronto, Seattle and
Budapest. Nobody can read the files without access to the original user's
cryptography key and password -- with the exception of sophisticated
code-cracking organizations such as the U.S. National Security Agency or
China's Public Security Bureau.
I might be missing something here but - exactly how does a system 
insecure enough that interested governments can crack it help protect 
people who are releasing information concealed by those governments?

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: A National ID

[Dave Howe]

R. A. Hettinga wrote:
If we're going to move to a national identification card, we can't afford
to do it badly. Now is the time to figure out how to create a card that
helps identify people but doesn't rob them of a huge swath of their civil
liberties in the process.
Just watch how the british do it - then don't do it that way.
I am still trying to figure out how over a decade of terrorist bombings 
in mainland UK didn't justify introducing a national ID card - but the 
americans wanting biometric passports for visitors does.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Russell Nelson]

I see that you are not interested in discussing the relative merits of
STARTTLS vs. DomainKeys, but instead are just trying to push
STARTTLS.  I hope that Perry will see through your sales job, and will
return your email to you, just as he will return this one to me.
-russ

[Moderator's note: No such luck for you I'm afraid. However, I'd
prefer if both of you tried to stay away from being personal. --Perry]

Peter Gutmann writes:
 > Russell Nelson <[EMAIL PROTECTED]> writes:
 > >Peter Gutmann writes:
 > >> STARTTLS
 > >
 > >If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
 > >handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
 > >nothing.  If Uma and Wendy implement DomainKeys, and Violet does not, and
 > >Violet handles email which is ultimately sent to Wendy, then Wendy can check
 > >Uma's signature.
 > 
 > Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
 > they are, DomainKeys accomplishes nothing.  OTOH if their { ISP, company,
 > whatever } has STARTTLS enabled, they're getting their email encrypted without
 > even knowing about it and are having better-than-average security applied to
 > their POP/IMAP mail account, again without even knowing about it (I suspect
 > the latter is far more of a selling point to users than encryption.  No-one
 > would want to read their mail anyway so they're not worried about that, but if
 > it stops those nasty hackers from breaking into their account, it's a good
 > thing).
 > 
 > >If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
 > >*need* to compare the email address on the incoming email.
 > 
 > He'd instead need to spend even more time mucking around with keyrings and
 > updating keys and writing scripts to handle all the checking and wondering why
 > it all has to be so complicated, and maybe he should just ask people to fax in
 > submissions.
 > 
 > Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Ed Gerck]

Peter Gutmann wrote:
The S/MIME list debated this some time ago, and decided (pretty much
unanimously) against it, for two reasosn.  Firstly, because it adds huge ugly
blobs of base64 crap to each message (and before the ECC fans leap in here,
that still adds small ugly blobs of base64 crap to each message).  Secondly,
because if you get a message from someone you know you'll be able to get a
pretty good idea of its authenticity from the content (for example an SSH
developer would be unlikely to be advocating SSL in a list posting), and if
you get a message from someone you don't know then it's pretty much irrelevant
whether it's signed or not.  So the consensus was not to sign messages.

What you're saying is that based on only *two* bits of information (e.g., SSH=1
and SSL=0) for a given mail sender, the message could be authenticated well-enough
to be useful in the operational context.
I agree with this and that's why I think that conventional digital signatures
with 1024-bit keys are an overkill for common email. If the ugly blob of base64
rubbish is small enough, it should be tolearable.
The problem with asymmetric keys, though, is that faking short signatures is
too trivial for current cryptosystems.
Cheers,
Ed Gerck
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Dave Howe]

Peter Gutmann wrote:
It *is* happening, only it's now called STARTTLS (and if certain vendors
(Micromumblemumble) didn't make it such a pain to set up certs for their MTAs
but simply generated self-signed certs on install and turned it on by default,
it'd be happening even more).
TLS for SMTP is a nice, efficient way to encrypt the channel. However, 
it offers little or no assurance that your mail will *stay* encrypted 
all the way to the recipients.
Most of us (including me most of the time) are in the position of using 
their ISPs or Employer's smarthost to relay email to its final 
destination; in fact, most employers (and many ISPs) actually enforce 
this, redirecting or blocking port 25 traffic.
If my employer or isp accept TLS traffic from me, but then turn around 
and send that completely unprotected to my final recipient, I have no 
way of preventing or even knowing that.
Sendmail's documentation certainly used to warn this was the case - 
probably still does :)

How many messages to the Cryptography Mailing List are cryptographically
signed?
The S/MIME list debated this some time ago, and decided (pretty much
unanimously) against it, for two reasosn.  Firstly, because it adds huge ugly
blobs of base64 crap to each message (and before the ECC fans leap in here,
that still adds small ugly blobs of base64 crap to each message).  Secondly,
because if you get a message from someone you know you'll be able to get a
pretty good idea of its authenticity from the content (for example an SSH
developer would be unlikely to be advocating SSL in a list posting), and if
you get a message from someone you don't know then it's pretty much irrelevant
whether it's signed or not.  So the consensus was not to sign messages.
Agreed.  In cases of spoofing, there could of course be an issue - but 
lets be honest here; when was the last time a mailing list regular 
*anywhere* lost reputation because someone posted spam or trollishness 
to the list in their name?
I am not saying that doesn't happen - but it is rare, and usually the 
real poster points out the difference in header data that would indicate 
that email came from a source other than him.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Dave Howe]

Ed Gerck wrote:
No -- DomainKeys has nothingf to do with 'email cryptography'. They are
S/MIME and PGP/MIME.
I wouldn't say PGP/MIME (as opposed to pgp inline) was a widely enough 
used standard to be considered one of two options - pgp (both methods) 
certainly, but not pgp/mime exclusively.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: Yahoo releases internet standard draft for using DNS as public key server

[Peter Gutmann]

Russell Nelson <[EMAIL PROTECTED]> writes:
>Peter Gutmann writes:
>> STARTTLS
>
>If Alice and Cathy both implement STARTTLS, and Beatty does not, and Beatty
>handles email which is ultimately sent to Cathy, then STARTTLS accomplishes
>nothing.  If Uma and Wendy implement DomainKeys, and Violet does not, and
>Violet handles email which is ultimately sent to Wendy, then Wendy can check
>Uma's signature.

Since none of Uma, Wendy, or Violet implement DomainKeys or even know what
they are, DomainKeys accomplishes nothing.  OTOH if their { ISP, company,
whatever } has STARTTLS enabled, they're getting their email encrypted without
even knowing about it and are having better-than-average security applied to
their POP/IMAP mail account, again without even knowing about it (I suspect
the latter is far more of a selling point to users than encryption.  No-one
would want to read their mail anyway so they're not worried about that, but if
it stops those nasty hackers from breaking into their account, it's a good
thing).

>If, instead, Perry had a list of PGP keys and email addresses, he wouldn't
>*need* to compare the email address on the incoming email.

He'd instead need to spend even more time mucking around with keyrings and
updating keys and writing scripts to handle all the checking and wondering why
it all has to be so complicated, and maybe he should just ask people to fax in
submissions.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]