[Cryptography] psyops

[David Honig]

Bumber sticker:

Remember, the NSA is Backing You Up 


___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

"Scan design called portal for hackers"

[David Honig]

EETimes 25 Oct 04 has an article about how 
the testing structures on ICs makes them 
vulnerable to attacks.  The basic idea is
that to test a chip, you need to see inside
it; this can also reveal crypto details 
(e.g., keys) which compromise the chip.  

This has been known to us with an interest
in both crypto and IC design for some time,
but its nice to see it exposed in the public
lit.  There are methods that avoid this,
such as BIST, but they are less popular.





=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



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

Re: Linux-based wireless mesh suite adds crypto engine support

[David Honig]

At 03:25 PM 9/30/04 -0700, John Gilmore wrote:
>
>Crypto hardware that generates "random" numbers can't be tested in
>production in many useful ways.  My suggestion would be to XOR a
>hardware-generated and a software-generated random number stream.  If
>one fails, whether by accident, malice, or design, the other will
>still randomize the resulting stream.  Belt AND suspenders will keep
>your source of randomness from being your weakest link.

A good idea, but also: consider that hardware based RNGs are
not so hard to make.  An FM radio soundcard, audio digitizer, and
some homebrew (perhaps standard-crypto-hash-based) software
suffices for moderate bandwidth true RNG construction.  
Using an evaluation metric like Diehard and/or a Shannon or
Mauer entropy measure ices the cake (as well as being required
for initial and continuing monitoring).  (Insert the usual caveats
about PRNGs being undetectable, OS subversion, white vans driving
your FM hiss, etc.)  Very cheap and if you can master a hash
function component, not tricky.

Obviously too much trouble for Joe Sixpack, but I think that
certain online gambling houses (not US of course) have made
their own sources, and definately not too hard for anyone who codes
and has crypto-clue.  OTOH Joe can benefit from his radio-tuner
card plus off the shelf inspectable software since he ought not
to trust Bigcorp's embedded nominal RNG.  Joe Sixpack might also
be an abbreviation for a foreign government.  Should the Pakis
really trust Intel's RNG? 

PS: your belts and suspenders argument also applies to trusting
cipher algorithms.  Best to chain a few.  Also useful to twiddle
a few S-box bits, even if you get suboptimal properties, so as 
to deter cheap crackers using COTS cipher chips.  (Doing dictionary
regexp search, not the impractical exhaustive search, of course.)
This works particularly well in large random-S-box constructs like Blowfish
(et al) compared to the more spartan (thus degradable) DES S-boxes.

The weakest link will be bipedal for the forseeable future.










=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



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

Re: An interesting "new" computer security problem

[David Honig]

At 12:58 PM 9/27/04 -0600, Anne & Lynn Wheeler wrote:
>At 11:03 PM 9/24/2004, Peter Gutmann wrote:
>>A few days ago I was chatting with some people working on a government IT
>>project who had a rather complex security problem that they needed help
with.
>>They have a large number of users with Windows dumb terminals (think Xterms
>>but for Windows) connected to a central ASP server, which runs various
>>mutually untrusted apps from different vendors.  Their problem was that they
>>needed a means of securing the individual apps from each other.
>>
>>I told them that they were in luck, and this exact problem had already been
>>addressed before.  I'd drop off the detailed technical specs for the
solution
>>when I next saw them, they could recognise it by its bright orange cover.

Put each app on a separate machine, and don't put any networking
equiptment in the machines.  Simple.



=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted.  Really.

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



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

Re: "Approximate" hashes

[David Honig]

At 06:02 PM 9/1/04 +0300, Marcel Popescu wrote:
>From: "Marcel Popescu" <[EMAIL PROTECTED]>
>
>> Hence my question: is there some "approximate" hash function (which I
>could
>> use instead of SHA-1) which can verify that a text hashes "very close" to
>a
>> value? So that if I change, say, tabs into spaces, I won't get exactly the
>> same value, but I would get a "good enough"?

This is completely what secure hashes are supposed to prevent.  *Any* change
in the input will flip half the hash-bits on average.  Just like a block
cipher.  There is no input "nearness" preservation.  That's part of the point
of the algorithm.


>I just had an idea. Would this work?
>
>- let S be the input string, whose hash I want to verify
>- make S uppercase
>- remove everything but A-Z, 0-9, and common punctuation (!;:'",.?)
>- calculate the SHA1 hash of the result
>
>This should keep any insignificant changes out of the final result. 

You can encode your message in some format which is not subject
to mangling, and use a hash of that encoding.  You can then
decode the encoding back into unicode or whatever funky but
net-fragile character set you like.  This is somewhat like
ascii-armoring of PGP-encrypted messages.





=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



No, you're not 'tripping', that is an emu ---Hank R. Hill

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

Re: system reliability -- Re: titles

[David Honig]

At 12:12 AM 8/27/04 -0700, Ed Gerck wrote:
>
>David Honig wrote:
>> "Applications can't be any more secure than their
>> operating system." -Bram Cohen
>
>That sounds cute but I believe it is incorrect. Example: error-
>correcting codes. The theory of error-correcting codes allows
>information to be coded so that it can be recovered even after
>significant corruption. 

Yes.  But what makes you think the implementation you are
using is not subverted? 

What makes you trust your md5 (or whatever) calculator,
which is how/why you trust your downloaded code? 

And, summarizing a Turing award lecture, what makes you
trust your compiler, much less "ps" or other OS monitors? 

>What this means is that the search for the "perfect" operating
>system as the solution to security is backwards.

What it means is that the weakest link will break first.
Humans, generally.  Also the infrastructure under your
tools, ie OS.  And the tools used to build your tools, 
ie compilers or interpreters.

Its not a "search for a perfect" anything; its a recognition
that trust in a system relies on trusting a great number of things; 
if any one is toast, the system is toast.  

Ask Niko Scarfo... used great crypto, but a $10 keylogger
got him.  He might have run the most secure MULTICs around,
but the weakest link was his keyboard, and a black-bag job.



=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



No, you're not 'tripping', that is an emu ---Hank R. Hill

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

Re: titles

[David Honig]

At 12:34 AM 8/27/04 +0100, Ian Grigg wrote:
>
>David Honig wrote:
> > "Security Engineer", according to Schneier...
>
>I don't like that term for 3 reasons:  firstly, when we
>build stuff, security should be top-to-bottom, integrated
>in, and not seen as an add-on, an after-thought.  That
>is, the overall engineer should build in the security as
>required from the beginning, so it is a skill that all
>need, and not something thrown over the wall to the guy
>with "security" in his title.

It should be, but usually isn't.  In fact, the security
dude often has to make recommendations out of his
prescribed niche, to others.  Often on a project which
is already under way.

E.g., I recently contracted to implement a crypto protocol.
When I suggested that, if a pad of paper be provided for
folks to write their passphrases down, it be a single 
glass-backed sheet (lest impressions be taken), much
laughter ensued.  But if its worth encrypting, it must
be interesting, right?   


>Secondly, anything to do with security has a very strong
>hype-to-value ratio, so much so that it's quite hard to
>find a "security" company selling good security stuff.

Security is much more than crypto, I've learned, so 
I don't have a problem with the word.  Security includes
human and physical security, and although they're not
cool comp sci or math, they are vital.  Crypto being
fairly refined, its not the weakest link any more.  And a 'security'
mindset (being able to think like the adversary, much
like in tic-tac-toe or chess) is important, but not
so common.

Its not like things titled "crypto" aren't often marianated in snake oil...
:-)

>Thirdly, good security engineering, as it should be done,
>doesn't necessarily involve crypto.  The art is in using
>as little crypto as possible - in precise and well placed
>doses.  IMHO.  

Yes.

"Applications can't be any more secure than their
operating system." -Bram Cohen

Oftentimes, however, security engineers
>start from the pov that crypto is a hammer, and their
>job is to go find a nail to encrypt.

I'll admit to this tunnel vision when I started my interest,
over a decade ago when I learned how the IP worked and
got into dissecting crypto algorithms to find the magic.
Since then I've learned that other things are more 
important to understand; crypto components are just black 
boxes to an engineer, like a sorting routine or the like.

Cryptoplumber is cute, in a self-depreciating way, but
its all engineering, albeit less mature than say civil
engineering, which stopped building bridges that collapse
some time ago.

"The ultimate in paranoia is not when everyone is against you but when
everything is against you." --PKD


=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



No, you're not 'tripping', that is an emu ---Hank R. Hill

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

Re: How thorough are the hash breaks, anyway?

[David Honig]

At 11:09 AM 8/26/04 -0400, Trei, Peter wrote:
>[Disclaimer: I've never claimed to be a mathematician, nor even a
>cryptographer:my business card says 'cryptoengineer'. I've always 
>tried more to understand how to  properly use cryptographic 
>primitives than to understand the deep theory of their construction. 
>I go to people who know the theory when I have a question, 
>and they come to me when they need something designed and 
>built correctly and well.]

"Security Engineer", according to Schneier...

>Looking over the recent work on hash collisions, one
>thing that struck me was that they all seem to be 
>attacks on known plaintext - the 'plaintexts' which
>collided were very close to each other,  varying in 
>only a few bits. 
>
>While any weakness is a concern, and I'm not
>going to use any of the compromised algorithms
>in new systems, this type of break seems to be
>of limited utility. 
>
>It allows you (if you're fortunate) to modify a signed
>message and have the signature still check out. 
>However, if you don't know the original plaintext
>it does not seem to allow you construct a second
>message with the same hash.

A canonical example of where a MAC is used is in
sending a contract, where the Adversary wants to change
the amount of a particular field, eg a money-value.
The contract (eg, stock transactions) itself is not
encrypted.

In these rare (toy?) instances (of integrity but not confidentiality)
the plaintext is available.  So a MAC-attack makes the 
"irrefutability" assurance it provides into toast.

By encrypting the message you make it much harder.


PS: The NIST has a CDROM of hashes of "common" files so
that forensics types can ignore them.  (Or if they're stego
programs, notice them..)  That CDROM uses
multiple algorithms ---for each file there is an MD5, SHA-1,
etc. hash.  Rather hard to find collisions for multiple
algorithms :-) although polymorphism can move a program
from "suspect" to "unknown".






=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



No, you're not 'tripping', that is an emu ---Hank R. Hill

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

Re: RPOW - Reusable Proofs of Work

[David Honig]

At 04:34 PM 8/20/04 -0500, Matt Crawford wrote:
>>> I'm wondering how applicable RPOW is.  
>
>If you think of POW as a possible SPAM mitigation

As spam mitigation, it might work better than
hashcash.  As cash, it lacks the anonymity of 
"bearer-documents (tm)" since there is one
clearing house.  This might be improved via
support for a system of mostly independent
clearing houses which also interchange at 
interchange places.  However, those would likely
be regulated by the Powers That Be, ergo not
alleviating my concerns about anonymity.

My 2 dinars.


=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP

ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB



No, you're not 'tripping', that is an emu ---Hank R. Hill

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

Re: should you trust CAs? (Re: dual-use digital signature vulnerability)

[David Honig]

At 02:09 PM 7/28/04 -0400, Adam Back wrote:
>The difference is if the CA does not generate private keys, there
>should be only one certificate per email address, so if two are
>discovered in the wild the user has a transferable proof that the CA
>is up-to-no-good.  Ie the difference is it is detectable and provable.

Who cares?  A CA is not legally liable for anything they
sign.  A govt is not liable for a false ID they issue
a protected witness.  The emperor has no clothes, just
a reputation, unchallenged, ergo vapor.




=
36 Laurelwood Dr
Irvine CA 92620-1299

VOX: (714) 544-9727 (home) mnemonic: P1G JIG WRAP
VOX: (949) 462-6726 (work -don't leave msgs, I can't pick them up)
   mnemonic: WIZ GOB MRAM
ICBM: -117.7621, 33.7275
HTTP: http://68.5.216.23:81 (back up, but not 99.999% reliable)
PGP PUBLIC KEY: by arrangement

Send plain ASCII text not HTML lest ye be misquoted

--

"Don't 'sir' me, young man, you have no idea who you're dealing with"
Tommy Lee Jones, MIB

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

Re: Is finding security holes a good idea?

[David Honig]

At 02:12 PM 6/16/04 -0700, Eric Rescorla wrote:
>Thor Lancelot Simon <[EMAIL PROTECTED]> writes:

Have neither of you considered why people write
open-sourced code?  Reputation, to learn, utility, etc.
With the exception of perhaps security-focussed
code, no one gains much reputation by *finding*
bugs whereas contributing a package of functionality
(buggy or not) wins community points.

In short, aside from common cognitive foibles
which you're discussing, 
the open-source reward system doesn't make heroes of bug
finders.  Eg I might know the name of the author
of eg sendmail, but do you know the names
of anyone who found a security bug in that code? 
(Not including people you knew before).





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

Re: Is finding security holes a good idea?

[David Honig]

At 08:40 AM 6/16/04 -0700, Eric Rescorla wrote:
>> the search patterns used by blackhats - we are all human and are likely
>> to be drawn to similar bugs. 

Prof Nancy Levenson once did a study where separate teams coded
solutions to the same problem.  The different teams' code often erred
in the same places (eg corner cases).  This was taken as
an argument against N-version programming IIRC.  It supports
the argument that H. saps are succeptible to common cogntive
flaws.  While this was a code *generation and test* experiment,
it does bear on the "evaluate for bugs" question too.

As far as whether finding holes is a good idea, remember that
the Pros do not report what they find.  
No means or methods, remember? 




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

Re: my periodic rant on quantum crypto

[David Honig]

At 03:37 PM 4/12/04 -0400, Perry E. Metzger wrote:
>
>QC can only run over a dedicated fiber over a short run, where more
>normal mechanisms can work fine over any sort of medium -- copper, the
>PSTN, the internet, etc, and can operate without distance limitation.


Nice essay.  I especially liked the discussion of authentication.

Its also the case AFAIK that the quantum-carrying fiber
can only carry one photon at a time.  (Perhaps you can multiplex
different frequencies, if your demultiplexor doesn't change the
quantum properties).  Now while there *is* a lot of dark fiber,
sending one photon at a time is a pretty good way to keep the
construction crews digging up roads :-) 

Similar quantum-hype is sometimes argued in RNG discussions
by those with very narrow views of what an RNG needs and
consists of.



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

Re: Microsoft publicly announces Penny Black PoW postage project

[David Honig]

At 09:13 AM 12/26/03 -0800, Steve Schear wrote:
>http://news.bbc.co.uk/2/hi/technology/3324883.stm
>

>>Mr Wobber and his group calculated that if there are 80,000
seconds in a day, a computational "price" of a 10-second levy
would mean spammers would only be able to send about 8,000
messages a day, at most. 

"Spammers are sending tens of millions of e-mails, so if they had
to do that with all the messages, they would have to invest
heavily in machines." <<


Replace "invest" with "trojan" and remind Mr. W. that he
works for the major facilitator of trojaned machines.







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

Re: SSL, client certs, and MITM (was WYTM?)

[David Honig]

At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote:
>
>Indeed. Imagine if we waited until airplanes exploded regularly to
>design them so they would not explode, or if we had designed our first
>suspension bridges by putting up some randomly selected amount of
>cabling and seeing if the bridge collapsed. That's not how good
>engineering works.

No.  But how quickly we forget how many planes *did* break up,
how many bridges *did* fall apart, because engineering sometimes
goes into new territory.

Even now.  You start using new composite materials in planes, and wonder why
they fall out of the sky when their tails snap off.  
Eventually (though not yet) Airbus et al
will get a clue how they fail differently from familiar metals.  
Even learning about now-mundane metal fatigue in planes involved
breakups and death.

(Safety) engineering *is* (unfortunately, but perhaps by practical necessity)
somewhat reactive.  It tries very hard not to be, but it is.

dh





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

Re: WYTM?

[David Honig]

At 01:51 PM 10/16/03 -0400, Bryce O'Whielacronx wrote:
>  I doubt it.  It's true that VeriSign has certified this
man-in-the-middle
>   attack, but no one cares.  

Indeed, it would make sense for the original vendor website (eg Palm)
to have signed the "MITM" site's cert (palmorder.modusmedia.com),
not for Verisign to do so.  Even better, for Mastercard to have signed
both Palm and palmorder.modusmedia.com as well.  And Mastercard to
have printed its key's signature in my monthly paper bill.


(This is aside your main point about it being Mastercard et al. 
doing the checking/backup for the customer, not certs.)




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

Re: Open Source (was Simple SSL/TLS - Some Questions)

[David Honig]

At 12:08 AM 10/10/03 +0800, Ng Pheng Siong wrote:
>I believe SSL VPNs are easier than IPsec to deploy 

For the former, you give a password or two --maybe
reuse a POP3 that your users already have-- and all your
users get in fairly securely, and you can verify them.  
Easy for them because they already have a browser.  

(And some browsers, I recently found out, will accept a self-cert
for life, as well as remember your passwords.  Can you guess
which company made that convenience-vs-security tradeoff?)

For IPsec, you have to walk each of them through
installing the stack, etc.  Not fun, esp on multiple
platforms.

and operate for the road
>warrior accessing corporate resources. This may eventually restrict IPsec's
>utility to site-to-site tunneling (useful when, e.g., one wishes to run
>OSPF over the tunnel), which _should_ be far easier to configure without
>needing the help of some whizbang AI.

Things *should* get easier for IPsec when its part of the "default"
client system, whether *nix or otherwise.  Then everything reverts
back to simple :-) key management.


He say "I know you, you know me"
He got x509 he got intrusion detection
He got secure DNS he got spam filter
He say "One and one and one is three"
Got to be spoofed 'cause he's so hard to see 

>From Link Together
J0hn L3nn0n





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

Re: anonymous DH & MITM

[David Honig]

At 03:38 PM 10/6/03 -0400, Ian Grigg wrote:
>I'm asking myself whether "anonymous DH" is confusingly named.
>Perhaps it should be called psuedonymous DH because it creates
>psuedonyms for the life of the session?  Or, we need a name
>that describes the creation of psuedonyms, de novo, from
>an anonymous starting position?

Think of an "identity" is one endpoint of a communication link.

Identities can have varying degrees of persistance
and varying degrees of association with meatspace/bank accounts.
These are orthogonal dimensions.

An endpoint can maintain a reputation (persistant "identity")
but need not be linked to meatspace entity.  A nom-de-plume
is a traditional example.

By itself, DH exchange only assures that the endpoints
remain constant (plus, via the typical symmetric key
exchange, also provides confidentiality) for the session.
If there is a MITM, the endpoints are not what the
distal endpoints (Alice & Bob) might think.

RSA-certs as administered by Verislime have very little
meatspace linkage --you can't sue Verislime if their
signed-claims about a meatspace entity are untrue, and
the certholder ran off with your money, or if the 
cert was copied and your DNS cache poisoned.

Similarly, publishing a RSA public key and email address
does not guarantee anything.  And since trust is *not*
transitive, the so-called "web of trust" does little
to help, because your personally trusted associates may have
been compromised.

And of course single meatspace entities may have several RSA
keys which others do not know have a common user.








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

Re: Can Eve repeat?

[David Honig]

At 08:34 AM 9/24/03 -0400, Greg Troxel wrote:
>A consequence of the infinite CPU assumption is that ciphers like AES,
>hash functions like SHA-1, etc. are all considered useless by the
>purist QC community.  Thus, people talk about doing authentication
>with families of universal hash functions.  This has the practical
>problem that the original (courier-transported) secret keying material
>for authentication is used up, and the typical scheme talked about is
>using some of the agreed-upon QKD bits to replenish the authentication
>keying material.  This does not seem very robust.  

Those couriers are carrying one-time pad CDs, in a QC world.

Do not try to pet their dogs, BTW.





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

Re: Simple inner transposition steganography

[David Honig]

At 08:21 PM 9/18/03 +0200, edo wrote:
>Come on, this is a terrible idea for steganography.  Unless this catches
>on as some sort of fad, which (a) it won't and (b) even if it did it
>would be short-lived, then sending a message with its letters scrambled
>in this way would be the last thing you'd want to do for steganography.

Are you forgetting: 

1. the stego'ed bits are already noise (ie, encrypted),
possibly shaped noise?

2. you don't have to make a mistake on every word?

Ie, you model what human mispellers do and you can still have
deniable bandwidth.

...

Speaking of which, but aside: An alexic (due to MS disconnecting a certain
visual-to-linguistic path)  "hunt-and-peck" friend makes lettershape-based
errors when typing, vs. the spatial qwerty-finger-position-fumble errors
that I (an inaccurate touch typist) make, or the spelling errors ("I"
before "E" yadda yadda) that visually-literate, careful authors  make. 

[Some text-to-speech software is helping him regain functionality.  As does
Google's _did you mean?_, spellchecking, and his diary's (Excel, actually)
search ability.  GPS might help with his navigation problems.]

Anyway, there's a human-error-distribution which can be used to 
shape the stego'd misspellings.  Just like one's digital camera noise can be
characterized before using images from it to broadcast stego'd messages.








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

RE: Code breakers crack GSM cellphone encryption

[David Honig]

At 05:04 PM 9/8/03 -0400, Trei, Peter wrote:
>Why the heck would a government agency have to break the GSM encryption
>at all? The encryption is only on the airlink, and all GSM calls travel
>through 
>the POTS land line system in the clear, where they are subject to 
>warranted wiretaps.
>
>Breaking GSM is only of useful if you have no access to the landline
>portion of the system.

You forget that some regimes want to listen to GSM calls
in places that they don't control.







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

Re: Code breakers crack GSM cellphone encryption

[David Honig]

At 02:37 AM 9/9/03 +1000, Greg Rose wrote:
>At 05:18 PM 9/7/2003 -0700, David Honig wrote:
>>"Laughing my ass off."  Since when do governments care about patents?
>>How would this help/harm them from exploiting it?   Not that
>>high-end LEOs haven't already had this capacity ---Biham et al
>>are only the first *open* researchers to reveal this.
>
>Actually, patenting the method isn't nearly as silly as it sounds. Produced 
>in quantity, a device to break GSM using this attack is not going to cost 
>much more than a cellphone (without subsidies). Patenting the attack 
>prevents the production of the "radio shack (tm) gsm scanner", so that it 
>at least requires serious attackers, not idle retirees or jealous teenagers.

That sounds like a "lets make inexpensive guns illegal so only the
wealthy can have them" argument.  Or maybe a more Soviet "lets make
typewriters, xerox machines available only to those we trust".

The people who are into scanners (wealthy idle retirees, HAMS
demographically) etc. will have them, why not everyone?  In particular, and
cryptographically relevant, 
why continue a popular illusion that something is secure when its not?   

Should Blaze have published the locksmiths' master-key secret
and his detailed exploit? 
Any "idle retiree or jealous teen" can now get into places previously
(but erroneously) believed secure.  

(If some culture wants to, it can make the practice --scanning on 900Mhz,
going through a lock to trespass, exploiting a Windows security hole, 
or Biham et al's GSM attack-- illegal.   Patenting a method is not a very
good way to implement morality.  Neither will it constrain the interested
individual.)










I hope the discoverer's intent was only to make money.







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

Re: Code breakers crack GSM cellphone encryption

[David Honig]

At 03:32 PM 9/7/03 -0400, R. A. Hettinga wrote:
>If the cellphone companies in 197 countries want to correct the code errors
>that expose them to trickery and abuse, they will have to call in each
>customer to make a change in the cellphone's programming, or replace all of
>the cellular phones used by their subscribers.

I've read that the lifecycle of a cell phone is about 2 years, 
FWIW.

During a kids-channel TV show, I saw that if you buy 4 dolls
you get a prepaid phone free.  Took me a while to get over
that future-shock.

>A copy of the research was sent to GSM authorities in order to correct the
>problem, and the method is being patented so that in future it can be used
>by the law enforcement agencies.

"Laughing my ass off."  Since when do governments care about patents? 
How would this help/harm them from exploiting it?   Not that
high-end LEOs haven't already had this capacity ---Biham et al
are only the first *open* researchers to reveal this.









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

Re: Is cryptography where security took the wrong branch?

[David Honig]

At 10:18 AM 9/3/03 PDT, D. K. Smetters wrote:
>
>I find WEP very useful for one thing -- given the habit of
>many wireless clients to opportunistically jump onto any
>network they happen to find, turning on WEP keeps users
>from accidentally "falling" onto networks by mistake. 

This is much like the locks on cars.  They are basically
weak, but they prevent you from accidentally opening
the wrong car, should an identical one be parked near
yours.  Sort of like the locks on residential bathrooms
that can be opened with a paper clip.  Trivially brute
forced but useful nonetheless.

Or the no-tresspassing signs on barbed wire fences,
which are required by law, else the property is crossable.
(This is, in my mind, the common-law basis for
New Hampshire's "no password = freely usable" law
legalizing wardriving.)



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

Re: U.S. seeks OSCE pact on biometric passports

[David Honig]

At 04:50 PM 9/2/03 -0400, Duncan Frissell wrote:
>Anyone have any pointers to non destructive methods of rendering Smart
>Chips unreadable?  Just curious.
>
>DCF

Perhaps I'm being dense but how could this be non-destructive? 

Do you mean "non-obvious"?   Or "reversible"?

If the usual microwave games don't apply, perhaps sufficient
acceleration or ionic fluids would work.  Thermal stress
for the liquid nitrogen folks?  The flash unit from
a $4 disposable camera does a nice job of vaporizing a spot of 
metal from a coin or screwdriver shorting the cap.

Do any europeans have experience leaving smartcards in the laundry?

One question would be how to discretely test/verify the new read-not mode :-)







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

Re: traffic analysis (was: blackmail / stego)

[David Honig]

At 01:01 PM 8/27/03 -0700, Jim McCoy wrote:
>While IANL, it seems that the whole anonymity game has a flaw that 
>doesn't even require a totalitarian regime. I would direct you to the 
>various laws in the US (to pick a random example :) regarding 
>conspiracy. Subscribing to an anonymity service might not become 
>illegal, but if anyone in your "crowd" was performing an illegal action 
>you may be guilty of conspiracy to commit this action.  

Ok, so you have a EULA in which you prohibit "offensive" behavior.
A crowd-member might violate this, but any "chaff" crowd-member
would have a legal defense ---"Hey, I used the foobar service
to avoid hackers finding my IP, its not my fault if someone threatened the
king"

A real police state would just Tomahawk the servers.  After rubber
hosing the operators.  Anything less than a Total Police State
would have to acknowledge innocent subscribers.  

Kinda like (ca. 1980) yeah, I have a cell phone, its because I
am on the road ---I'm not a pharmdealer, even if half the carrier's
traffic is dubious.

Or, moving into this century, "yeah, I use KaZaa++, but its to 
download unrecognized indie bands, not MetalliMadonna"
(assuming K++ were anonymous..)

Of course, its becoming easier and easier to be a total police state..









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

Re: Abit's SecureIDE

[David Honig]

At 03:55 PM 8/22/03 -0700, bear wrote:
>>"40-bit DES (US Data Encryption Standard) is adequate for general users"
>
>Interesting.  Can these chips be usefully cascaded?

Why would you want to?  You can do a better cipher in an 
FPGA very cheaply.. eg 3DES..

You can cascade horses to pull your carriage faster,
but you'll do better with a gas engine..






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

Re: Information-Theoretic Analysis of Information Hiding

[David Honig]

At 12:30 AM 7/15/03 -0400, Don Davis wrote:
>"An electrical engineer at Washington University
> in St. Louis has devised a theory that sets the
> limits for the amount of data that can be hidden
> in a system and then provides guidelines for how
> to store data and decode it. Contrarily, the
> theory also provides guidelines for how an
> adversary would disrupt the hidden information.

"But the theory answers the questions, what is the optimal attack.."

There are ways of preventing any modification (attack) of the
carrier.  E.g., sign the carrier (with the private
half of a widely published public key).  Although this
technique would attract attention until widespread.

Note that Disney has to do this as well as Osama,
lest someone post Disney content, with the "not ok to copy freely"
watermark mutated.  Otherwise a downloader would
protest, "but the file said it was free, and the
included-file-hash said it was intact!"  (Because
the mutator also provided a new hash.)

(Disney's situation is worse, of course, because 
even the pristine, Disney-signed content is copyable at the
analog (etc) level.  And Osama can use multiple images as carriers
for a single message.)






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

Re: traffic analysis of phone calls?

[David Honig]

At 11:21 AM 7/12/03 -0400, Don Davis wrote:
> It often does not lie behind a firewall. Heck, it
> usually doesn't even lie behind a door. It has a direct
> connection to the Internet because, believe it or not,
> that is how the wiretap data is collected and transmitted."

I believe the CALEA specs call for the data to be encrypted
however.

The sophisticated spook/cartel also gets payphone logs
and does geographic matching.

How much does a free-lance counter-intel person make in Columbia?




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

Re: SSL

[David Honig]

At 10:49 AM 7/10/03 -0400, Ian Grigg wrote:
>that's another story, and I sense Perry's keenness
>to be less redundant and stay more ontarget.

Stretching Perry's limits...
In defense of Tom's point of view, code size does
matter in an embedded platform.  Methinks there's
a certain bias towards thinking that crypto only
runs on (massive) servers.  Sometimes you want a 
closed little box to run RSA ops, you want to use software,
and you can tolerate a slow rate number of transactions/sec.



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

Re: basic question: semantics of "map", "tie", etc in PKI

[David Honig]

At 11:40 AM 7/8/03 -0600, Anne & Lynn Wheeler wrote:
>A hardware token that requires a PIN/password to operate can be considered 
>two-factor authentication ("something you have" and "something you know"). 

I was going to comment on how a simple plastic debit card
that includes a photo provides the third "something you are".
(More reliably than the signature, which is also "something 
you are", but readily forged/ignored.)  

Then it occurred to me: as cameras become ubiquitous
(e.g., in cell phones) some extra security could be obtained
by sending a trusted photo of the account holder plus a live picture
of the card user.

A picture glued into the card could be forged, but a 
smartcard (with more data area than a magstripe)
could include a picture of the account holder,
so a thief has no idea what to look like.  But the vendor can
check the encrypted smartcard face to the face on the phone
or webcam.  For high-value remote transactions, this might
be viable in a few years.  

This is already standard practice
on high-security building-entry cards (and passports?), 
with the guard comparing the card-embedded face to the one before him.  
Ubiquitous cameras will bring that to remote transactions,
reducing cost due to lower fraud.









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

RE: Keyservers and Spam

[David Honig]

At 03:41 PM 6/13/03 -0700, Bill Frantz wrote:
>
>The HighFire project at Cryptorights
> is planning on building a
>"web of trust" rooted in the NGOs who will be using the system.  Each NGO
>will have a signing key.  A NGO will sign the keys of the people working
>for it.  In this manner, we have way of saying, "The John Jones who works
>for Amnesty International".  A NGO may decide to sign another NGO's signing
>key.  Now we have a way to say to someone in Amnesty, "Send a message to
>Steve Smith in Médecins Sans Frontières."  The plan is to show the trust
>relationship in the UI as a path of keys.
>
>I would appreciate your comments.

Threat model: NGO_Alice is compromised and signs GESTAPO key, leading
to NGO_Bob's demise.

Possible counters: 

NGO_Alice's NGO key is a split key, so >1 person needs
be rubber hosed.  I don't know if PGP supports this, I don't think so.

Short key expirations, in the limit trusted for just 1 day.  Already
possible, just document this.



Also, how do you counter the GESTAPO from seeing queries to the 
key servers?   It might be enough to jail anyone making such an
inquiry.  Possible solutions would include having the keyserver
perform some innocuous function, and use SSL for all connections
to it.  Also SSL proxying and stego of course.









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

RE: Keyservers and Spam

[David Honig]

At 05:47 PM 6/11/03 -0700, Bill Frantz wrote:
>To try to reflect some of David's points with a real-world situation.  I
>was at work, with a brand new installation of PGP.  I wanted to send some
>confidential data home so I could work with it.  However I didn't have my
>home key at work, so I didn't have a secure way to send either the data, or
>the work key.  I didn't even have the fingerprint of the home key.
>
>My solution was to pull Carl Ellison's business card out of my pocket.  It
>had his key fingerprint on it, and I remember getting it directly from him,
>so I could trust the fingerprint.  Now Carl had signed my key, so when I
>downloaded it from the key server, I could verify that it was indeed mine
>(to the extent I trusted Carl).  Carl's signature, and the key server
>allowed me to bootstrap trust into my own key.
>
>
>But with a key server, I didn't have to bother Carl to send me my key.  Or
>depend on him being online when I needed it.

True, although: 
1. you could have had your own key-fingerprint on your own bizcard
and done the same.  

2. you needn't have had your valid email address there (going back
to the spam-thread), perhaps just your regular name.  In fact you
could have your key on your home server, not in a public 
server which serves as spambait.  Your home server could be
"unlisted" by using an alternate port.  (I do this to get around
ISP blocking, but then I'm not trying to publish papers on my
home server.)  Or use CGI, or a password mechanism, to deter spam-spiders.

The point with spam and publishing your email address
is that its like having a public
physical storefront: anyone can pay the price of a cigarette 
to a stream of homeless people to
clog your physical store.  Or form a huge line if you have bouncers
at the door.  That's what having a public interface means.

3. I think you also trusted that Carl has not been compromised
and re-signed a bogus key *after* he first signed it.  (Not picking
on Carl here :-)





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

Re: An attack on paypal

[David Honig]

At 03:38 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
even before e-commerce, the real 
>BBB process was that people called up the BBB and got realtime information 
> i.e. it was an online, realtime process.
>
>the equiivalent for an online, internet paradigm (as opposed to something 
>left over from the offline email genre of at least 10--15 years earlier) 
>was that the browswer tab;e pf trusted entities were of online authorities 
>(as opposed to certificate manufacturing) and if you cared, you clicked 
>thru to the BBB and got realtime information about the merchant in question 
>(being equivalent to when people call the BBB to actually get some level of 
>real input  as opposed to just a fuzzy comfort fealing).

When I buy $20 of gas with non-bearer credentials (ie, credit card), 
the vendor does a real-time check on me.  Seems fair/useful to be able
to do same on them.  I suppose eBay's feedback suffices... if their
last N "feedbacks" are negative, I might go elsewhere.







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

Re: An attack on paypal

[David Honig]

At 12:42 PM 6/11/03 -0600, Anne & Lynn Wheeler wrote:
>At 10:56 AM 6/11/2003 -0400, Sunder wrote:
>>In either case, we wouldn't need to worry about paying Verisign or anyone
>>else if we had properly secured DNS.  Then you could trust those pop-up
>>self-signed SSL cert warnings.
>
>actually, if you had a properly secured DNS  then you could trust DNS 
>to distribute public keys bound to a domain name in the same way they 
>distribute ip-addresses bound to a domain name.

The DNS is like the Yellow Pages phonebook.  A secure DNS would prevent
evil postmen from editing your copy of the Yellow Pages before he drops it
off at your house. 

But *anyone* can buy an entry in the Yellow Pages.  And you can't
sue the Yellow Pages because of an advert there --even a signed (unedited)
one.

Adding PKeys to Yellow Pages merely lets you get scammed *confidentially*.

Verisign doesn't help ---they don't check anything in meatspace.  They're
not liable.  You can't sue them.  "Kosher meat certified by that 
vegetarian catholic up the street"

You need a Better Business Bureau's cert,  where the BBB is financially
liable.  
(This implies it checks in *meatspace* and probably implies competition too.)



Another metaphor: you can't sue the DMV if someone defrauds you using
a fake-ID.  

You can't sue the DMV even if its a valid ID.  You can't
get your money back if the valid ID points to someone who is no longer
bound to that name & location.

And getting scammed by whispering doesn't help either.



On the other hand, if reputation is all that matters, you can conduct
business without a fixed IP, DNS record, or Verisign, by transacting on a 
public bulletin board (skywriting), using only signatures to maintain the
rep (and provide confidentiality when exchanging credit card info).
There's a bootstrap
problem of building reps, and getting others to believe them, but Pkeys
let you maintain all the *identity* you need.






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

RE: Keyservers and Spam

[David Honig]

At 12:43 PM 6/10/03 -0400, Jeffrey Kay wrote:
>number (which I now use Call Intercept to avoid telephone solicitors).

But for privacy reasons, some folks will not automatically forward
their phone number.  You either deny them access or require them 
to jump through extra hoops (redial w/ special control codes 
that send their ID).  Analogy w/ email & PGP left as an exercise..







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

RE: Keyservers and Spam

[David Honig]

At 04:54 PM 6/10/03 +0100, [EMAIL PROTECTED] wrote:
>> From: David Honig 
>> Why not publish your key under a bogus name that goes no-where? 
>
>The answer is simple. I cannot publish a PGP under a false name, because if
>I did, who would sign it to attest that the genuinely did belong to the
>person to whom it claimed to belong? Would you?

I don't know you.  Why should I trust your signing of someone else's key?

If I know a mutual aquaintence, no need for "web of trust".

If some *random* person is writing to you, why do you, or they, care
who signed your key?  It merely provides confidentiality to the
key-holders.  It does *NOT* link your meatspace entity to your email address.

You might have separate keys (and separate emails) for each identity
you maintain.  None of which need be linked to your meatspace "true name".

In fact, you could have different identities of yours sign your other
keys, and the gullible would believe them (you)!  The eBay equivalent
is having one 'identity' give positive feedback about another 'identity',
fooling those who assume they are different physical-entities.



>If we allow this, then the entire web-of-trust disintegrates.

There *is no web of trust* unless you know the signers.  In which
case you may as well have them forward keys manually.

>I have seen very little discussion of this point, anywhere. 

The cypherpunks archives have discussion on the invalidity of
a "web of trust" signed by unknown (or corruptable) entities.

The few replies
>I have had to my original question suggest that there simply _is_ no
>solution, except live with it. Either don't publish your key (which means
>that no-one can find your key even if they have a priori knowledge of your
>email address), 

You email your key to those who justify the request.  In plaintext,
or on the phone.  What is the problem with that? 

Don't assume that the "web of trust" has anything to do with trust,
just because it (ab)uses that word.

Think about collusions of signers.  Think about multiple identities.
Remember that the Govt issues false "real-world" IDs when it is convenient
for them
to do so.

DH








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

Re: Keyservers and Spam

[David Honig]

At 11:51 AM 6/9/03 +0100, [EMAIL PROTECTED] wrote:
>Hi,
> 
>It seems to me that the possibilty that spammers might harvest PGP
>keyservers for email addresses is a serious disincentive to using
>keyservers. Does anyone have any thoughts on this?

Why not publish your key under a bogus name that goes no-where? 

Analgously: I don't publish my name with my phone number, I am listed under
a nym.  (Its free, and being unlisted isn't.)  If I need to tell
someone how to look me up if they're in town (and if they've forgotten 
the phone number I've personally given them) I refer them to the alias.  
The alias is somewhat mnemonic (my housecat's name) so they can remember it.

Its more convenient if key recipient can rename the key so your tools
automatically recognize it.


BTW, here's another reason not to publish your address and keys.
Aside from the fact that broadcast+stego communication is more discreet, 
what's to stop an  from sending *encrypted* mail
to all the addresses on a server, serving two purposes: 1. stuffing
the NSA's inbox with folks to watch 2. covering up his true communication
partner.  Probably the social-network-inference codes can filter most
of this TLA-spam, but hitting innocents with blatantly encrypted messages
from  would be an interesting hack.





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

Re: "PGP Encryption Proves Powerful"

[David Honig]

At 01:22 PM 5/29/03 -0400, Ian Grigg wrote:
>The following appears to be a bone fide case of a
>threat model in action against the PGP program.
>
>Leaving aside commentary on the pros and cons
>within this example, there is a desparate lack of
>real experience in how crypto systems are attacked.

There's also the possibility of disinfo.  For instance,
we all know that more competent agencies than the FBI
were involved.  

The real test of TLA abilities will be to see how many 
Red Brigaders are captured in coming months.  Assuming
that those captures are reported --which they might not,
to conceal TLA abilities.  (Remember Coventry?)

On the other hand, continued R.B. activities would be 
evidence that their hardware, software, and opsec were strong.





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