[Moderator's note: I posted on this earlier, but I really do want to
see Bletchley Park maintained... :) --Perry]
IBM and PGP have donated $100,000 to help restore and maintain
Bletchley Park as a museum. This money is intended to get others
involved - millions more will be needed.
From an article about WAN optimization appliances in Computerworld:
In some markets, such as health and finance, [hiring] a managed
provider [who will do the encryption outside your routers] isn't a
good option for another reason: Because data is optimized in an
unencrypted state,
Not cryptography, but ultimately what we talk about here often comes down to
protection that actually works *for people*.
Also a good counter to arguments of the form if only people were more
careful
-- Jerry
From:[EMAIL
| One thing to consider is that an idiom like this solves an annoying
problem.
| Consider a linear search through an array:
|
| for (i = 0; i lim; i++)
| { if (a[i] == target)
| { do something
| break;
| }
| }
|
[Moderator's note: forwarded on Jerry's behalf -- he's having mail problems.]
| So wouldn't the world be a better place if we could all agree on a
| single such library? Or at least, a single API. Like the STL is for C++.
|
|
|
| Yes, absolutely, but who is going to do it?
|
| One could
| Computer Hardware Software
| Escaping Password Purgatory
| David M. Ewalt, 08.03.05, 3:00 PM ET
|
| ... I think I have passwords for
| over 47 different applications both internal and external that I access,
| and I've acquired those IDs and passwords over several years, says Wayne
|
| Hi all,
|
| My question relates to hash functions in general and not specifically
| cryptographic hashes. I was wondering if there exists a group of hash
| function(s) that will return an identical result for sequentially
| similar yet rotate/shift wise dissimilar input:
|
| ie: input1 :
| Jerrold Leichter wrote:
| It's also clear that they don't expect customers to look closely at, or
| question, their bills. If they did, they'd make sure that meaningful
merchant
| names appeared on the bills, or at least were available if you called to ask
| about a charge.
|
| a company
| one of the business processes is that somebody calls their issuing
| bank and disputes a charge by a specific merchant on such such a date.
| the issuing bank eventually provides notice to the merchant (giving the
| account number, date, and purchase details). the merchant then looks for
| a
| an analogy i've used recently with respect to userid/password paradigm,
| is that account numbers are being concurrently used for both the userid
| function (requiring security *integrity* but not security
| *confidentiality*) as well as the password function (requiring strong
| security
| Date: Wed, 13 Jul 2005 16:08:20 -0400
| From: John Denker [EMAIL PROTECTED]
| To: Perry E. Metzger [EMAIL PROTECTED]
| Cc: cryptography@metzdowd.com
| Subject: Re: ID theft -- so what?
| ...
| Scenario: I'm shopping online. Using browser window #1, I
| have found a merchant who sells what I
| Jerrold Leichter [EMAIL PROTECTED] writes:
| In doing this calculation, be careful about the assumptions you make
| about how effective the countermeasures will be. The new systems
| may be more secure, but people will eventually come up with ways to
| break them. The history of security
| Suppose you have something that is inadvertently an
| oracle - it encrypts stuff from many different users
| preparatory to sending it out over the internet, and
| makes no effort to strongly authenticate a user.
|
| Have it encrypt stuff into a buffer, and on a timer
| event, send out the
| A brief altercation this evening with CERT over the recent hyperthread caching
| issues has brought something that's been simmering at the back of my brain to
| the forefront.
|
| The recent hyperthread/cache key recovery trick, followed by DJB's related
| (IMO) symmetric key recovery, and
| It's much harder to see how one could attack a session key in a properly
| implemented system the same way. You would have to inject a message into
| the ongoing session. However, if the protocol authenticates its messages,
| you'll never get any response to an injected message. At best,
| Uhh, that wasn't really what I was after, that's pretty much textbook stuff,
| what I wanted was specifically advice on how to use block ciphers in a way
| that avoids possibilities for side-channel (and similar) attacks. I have some
| initial notes that can be summarised as Don't let yourself
| Perry makes a lot of good points, but then gives a wrong example re Amex site
| (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL
| Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of
| the few companies that actually responded seriously to my
| Hi,
|
| you most probably have heard about the court case where the presence
| of encryption software on a computer was viewed as evidence of
| criminal intent.
|
| http://www.lawlibrary.state.mn.us/archive/ctappub/0505/opa040381-0503.htm
|
, approx, authorize, agree
| ... misc. past finread postings:
| http://www.garlic.com/~lynn/subpubkey.html#finread
|
|
| Jerrold Leichter wrote:
| This is a rather bizarre way of defining things. Something you have is a
| physical object. On the one hand, any physical object can be copied
| Really? How does one go about proving the security of a block cipher?
They don't claim that:
This cipher is ... provably just as secure as AES-128.
I can come up with a cipher provably just as secure as AES-128 very quickly
(Actually, based on the paper a while back on many
| Jerrold Leichter writes:
| They don't claim that:
|
| This cipher is ... provably just as secure as AES-128.
|
| I can come up with a cipher provably just as secure as AES-128 very
quickly
|
| Actually, I think Adam is totally right.
|
| Have you looked at their scheme?
| http
| if a re-issued a new token/card (to replace a lost/stolen token/card) is
| identical to the lost/stolen token/card ... then it is likely that there is no
| something you have authentication involved (even tho a token/card is
| involved in the process) ... and therefor the infrastructure is just
| [1] This is also my solution to the famous trust paradox proposed by Ken
| Thompson in his Reflections of Trusting Trust. Trust is earned, not
| given. To trust Ken's code, I would first ask two or more programmers (who
| I choose) to code the same function and submit their codes to tests. If
| I think you meant ECB mode?
|
| No, I meant CBC -- there's a birthday paradox attack to watch out for.
|
| Yep. In fact, there's a birthday paradox problem for all the standard
| chaining modes at around 2^{n/2}.
|
| For CBC and CFB, this ends up leaking information about the XOR of
| No, I meant CBC -- there's a birthday paradox attack to watch out for.
|
|
| Yep. In fact, there's a birthday paradox problem for all the standard
| chaining modes at around 2^{n/2}.
| For CBC and CFB, this ends up leaking information about the XOR of a couple
| plaintext blocks
| You're letting your intuition about usable randomness run roughshod
| over the formal definition of entropy. Taking bits out of the PRNG
| *does* reduce its entropy.
|
| By how much exactly? I'd say, _under the hypothesis that the one-way
| function can't be broken and other attacks fail_,
|
| random number generator this way. Just what *is*
| good enough?
|
| That's a good question. I think there is a good answer. It
| sheds light on the distinction of pseudorandomness versus
| entropy:
|
| A long string produced by a good PRNG is conditionally
| compressible
From Computerworld:
Microsoft Scales Back Passport Ambitions
Microsoft's decision to reposition its .Net Passport identification
system comes as Monster.com is dropping support for the authentication
service.
| It turns out that their techniques aren't all that useful.
| Changing laser printer cartridges changes the results.
| You might find that two documents were printed
| by the same printer, but it doesn't give you the
| options for tracking it down that manual typewriters did.
Actually, they say
| nilsimsa
| Computes nilsimsa codes of messages and compares the codes and finds
| clusters of similar messages so as to trash spam.
|
| What's a nilsimsa code?
|
| A nilsimsa code is something like a hash, but unlike hashes, a small change
| in the message results in a small change in the
| Bear writes:
| One interesting idea which I came up with and haven't seen a way
| past yet is to XOR each block with a value computed from its
| sequence number, then compute the hash function on the blocks in
| a nonsequential order based on the plaintext of the blocks
| in their new
| However ... *any* on-line algorithm falls to a Joux-style attack. An
| algorithm with fixed internal memory that can only read its input linearly,
| exactly once, can be modeled as an FSM. A Joux-style attack then is: Find
| a pair of inputs M1 and M1' that, starting from the fixed
| ... the comments I've seen on this list and elsewhere have been much
| broader, and amount to QM secure bit distribution is dumb, it solves
| no problem we haven't already solved better with classical
| techniques.
|
| Most of the comments on this list are more nuanced than that.
Perhaps we
| Alternatively, how anyone can have absolute confidence in conventional
| crypto
| in a week when a surprise attack appears against a widely-fielded
| primitive
| like MD5 is beyond me. Is our certainty about AES's security really any
| better today than was our certainty about RIPEM - or
| It strikes me that Joux's attack relies on *two* features of current
| constructions: The block-at-a-time structure, and the fact that the state
| passed from block to block is the same size as the output state. Suppose we
| did ciphertext chaining: For block i, the input to the
| the issue in the EU FINREAD scenario was that they needed a way to
| distinguish between (random) data that got signed ... that the key owner
| never read and the case were the key owner was actually signing to
| indicate agreement, approval, and/or authorization. They specified a
| FINREAD
| note that some of the online click-thru contracts have been making
| attempt to address this area; rather than simple i agree/disagree
| buttons ... they put little checkmarks at places in scrolled form you
| have to at least scroll thru the document and click on one or more
| checkmarks
| another purpose -- preserving the privacy of drivers by using more
| complicated protocols. However, as the benefit of such systems is to
| people who are unlikely to have much voice in the construction of the
| system, and who are also unlikely to be willing to pay more money to
| gain
| ...unless people are willing to go very hi-tech in their toll evasion
| maneuvers, implementing, say, thin see-through LCD screens placed over their
| license plates that turn opaque at a push of a button
A local TV station here in the NY area did a show about a lower-tech version
of the
| No mention is made of encryption or challenge response
| authentication but I guess that may or may not be part of the design
| (one would think it had better be, as picking off the ESN should be duck
| soup with suitable gear if not encrypted).
|
| From a business perspective, it makes
| Thor Lancelot Simon [EMAIL PROTECTED] writes:
|
| On Mon, Jun 14, 2004 at 08:07:11AM -0700, Eric Rescorla wrote:
| Roughly speaking:
| If I as a White Hat find a bug and then don't tell anyone, there's no
| reason to believe it will result in any intrusions. The bug has to
|
| I don't
| privacy wrote:
| [good points about weaknesses in adversarial system deleted]
|
| It's baffling that security experts today are clinging to the outmoded
| and insecure paper voting systems of the past, where evidence of fraud,
| error and incompetence is overwhelming.
| Non-repudiation applied to digital signatures implies that the definition
| states that only one person possibly had possession of the private signing
| key and was conscious about the fact that it was used to sign something.
There is absolutely *no* cryptographic or mathematical content to this
Now that we've trashed non-repudiation ... just how is it different from
authentication? In both cases, there is a clear technical meaning (though as
with anything in mathematics, when you get right down to it, the details are
complex and may be important): To produce an
| David Wagner writes:
|
| To see why, let's go back to the beginning, and look at the threat
| model. If multiple people are doing shared development on a central
| machine, that machine must have an owner -- let's call him Linus. Now
| ask yourself: Do those developers trust Linus?
|
|
| Rick Wash wrote:
| There are many legitimate uses of remote attestation that I would like to
| see. For example, as a sysadmin, I'd love to be able to verify that my
| servers are running the appropriate software before I trust them to access
| my files for me. Remote attestation is a good
(The use of memory speed leads to an interesting notion: Functions that are
designed to be differentially expensive on different kinds of fielded hardware.
On a theoretical basis, of course, all hardware is interchangeable; but in
practice, something differentially expensive to calculate on an
Ian's message gave a summary that's in my accord with how courts work. Since
lawyers learn by example - and the law grow by and example - here's a case
that I think closely parallels the legal issues in repudiation of digital
signature cases. The case, which if I remember right (from hearing
| Note that there is no theoretical reason that it should be
| possible to figure out the public key given the private key,
| either, but it so happens that it is generally possible to
| do so
|
| So what's this generally possible business about?
|
| Well, AFAIK its always possible, but I
| On Dec 27, 2003, at 10:01 AM, Ben Laurie wrote:
| Note that there is no theoretical reason that it should be possible
| to figure out the public key given the private key, either, but it so
| happens that it is generally possible to do so
| So what's this generally possible business about?
|
| We've met the enemy, and he is us. *Any* secure computing kernel
| that can do
| the kinds of things we want out of secure computing kernels, can also
| do the
| kinds of things we *don't* want out of secure computing kernels.
|
| I don't understand why you say that. You can build
| Which brings up the interesting question: Just why are the reactions to
| TCPA so strong? Is it because MS - who no one wants to trust - is
| involved? Is it just the pervasiveness: Not everyone has a smart card,
| but if TCPA wins out, everyone will have this lump inside of their
|
| NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard
| that will specify an additional hash function, SHA-224, that is based on
| SHA-256. The change notice is available at
| http://csrc.nist.gov/publications/drafts.html. NIST requests comments for
| the change notice
| Is it safe to use Pohlig-Hellman encryption with a common modulus?
| That is, I want various parties to have their own exponents, but share
| the same prime modulus. In my application, a chosen plaintext attack
| will be possible. (I know that RSA with common modulus is not safe.)
The question
| Does anyone know of a trapdoor one-way function whose trapdoor can be locked
| after use?
|
| It can be done with secure hardware and/or distributed trust, just delete
| the trapdoor key, and prove (somehow?) you've deleted it.
|
| It looks hard to do in trust-the-math-only mode...
You're going
| As David Wagner points out, encryption with a public key (for which the
| private key has been discarded) would seem to work.
There's something seriously wrong here, however. There are many close, but
not identical, definitions, of a one-way hash. While none of them explicitly
say so, many
| I listened to yet another talk on computer security, which
| incorporated security. It got me to thinking two things:
|
| o Pseudo-random implies pseudo security.
|
| If you're re-keying by running the old key through a pseudo-random
| function without adding any new entropy, then you're not
| I've not read the said article just yet, but from that direct quote as
| the copy degrades... I can already see the trouble with this scheme:
| their copy protection already fails them. They allow copies to be made
| and rely on the fact that the CDR or whatever media, will eventually
|
| From: Jill Ramonsky [EMAIL PROTECTED]
| From: Ian Grigg [mailto:[EMAIL PROTECTED]
|
| The only question I wasn't quite sure of
| was whether, if I take your code, and modify it,
| can I distribute a binary only version, and keep
| the source changes proprietary?
|
| You can't
[Using multiple channels on the assumption that the MITM can't always get all
of them.]
This is starting to sound like some very old work - to which I don't have a
reference - on what was called the wiretap channel. Basic idea: Alice and
Bob wish to talk; Carol can listen in to everything, but
| This is the second significant problem I have seen in applications that use
| ASN.1 data formats. (The first was in a widely deployed implementation of
| SNMP.) Given that good, security conscience programmers have difficultly
| getting ASN.1 parsing right, we should favor protocols that use
| From: Tim Dierks [EMAIL PROTECTED]
|
| I'm lost in a twisty page of MITM passages, all alike.
|
| My point was that in an anonymous protocol, for Alice to communicate with
| Mallet is equivalent to communicating with Bob, since the protocol is
| anonymous: there is no distinction. All the
| Date: Fri, 3 Oct 2003 10:14:42 -0400
| From: Anton Stiglic [EMAIL PROTECTED]
| To: Cryptography list [EMAIL PROTECTED],
| Tim Dierks [EMAIL PROTECTED]
| Subject: Re: anonymous DH MITM
|
|
| - Original Message -
| From: Tim Dierks [EMAIL PROTECTED]
|
|
| I think it's a tautology:
| From: Anton Stiglic [EMAIL PROTECTED]
| From: Jerrold Leichter [EMAIL PROTECTED]
| No; it's false. If Alice and Bob can create a secure channel between
| themselves, it's reasonable to say that they are protected from MITM
| attacks if they can be sure that no third party can read
| Date: Fri, 03 Oct 2003 17:27:36 -0400
| From: Tim Dierks [EMAIL PROTECTED]
| To: Jerrold Leichter [EMAIL PROTECTED]
| Cc: Cryptography list [EMAIL PROTECTED]
| Subject: Re: anonymous DH MITM
|
| At 03:28 PM 10/3/2003, Jerrold Leichter wrote:
| From: Tim Dierks [EMAIL PROTECTED]
| | No; it's
| Can be relied on to _only_ deliver text is a valuable and important
| piece of functionality, and a capability that has been cut out of too
| many protocols with no replacement in sight.
While I agree with the sentiment, the text/code distinction doesn't capture
what's important.
Is HTML
66 matches
Mail list logo
