[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real
problem
| is the key handling (how to make sure the DBA can't get the key,
cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax or the like to see if the
[EMAIL PROTECTED] wrote:
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax
On Fri, Jun 10, 2005 at 01:11:45PM -0400, [EMAIL PROTECTED] wrote:
| Ben Laurie wrote
| Sure, but Equifax should.
|
| No, they shouldn't! If you think they should, you are missinformed. At
| least in Canada, the Privacy Act protects the SIN, Equifax cannot demand
| it.
| See for example
|
[EMAIL PROTECTED] wrote:
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a
check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax
Jerrold Leichter [EMAIL PROTECTED] writes:
They also sold a full solution for encrypted Ethernet - KDC, encrypting
Ethernet adapters, associated software. None of this stuff went anywhere.
People just weren't interested.
That wasn't quite the case for the Ethernet encryption. What happened
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote:
Yes, encrypting indexed columns for example is a problem. But if you
limit yourself to encrypting sensitive information (I'm talking about
stuff like SIN, bank account numbers, data that serves as an index to
external databases and are
On Wed, 8 Jun 2005, David Wagner wrote:
[...]
That said, I don't see how adding an extra login page to click on helps.
If the front page is unencrypted, then a spoofed version of that page
can send you to the wrong place. Sure, if users were to check SSL
certificates extremely carefully, they
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key
From: Charles M. Hannum [EMAIL PROTECTED]
I can name at least one obvious case where sensitive data -- namely credit
card numbers -- is in fact something you want to search on: credit card
billing companies like CCbill and iBill. Without the ability to search by
CC#, customers are pretty
On Thursday 09 June 2005 17:37, Charles M. Hannum wrote:
If we assume that the last 4 digits have been exposed somewhere -- and they
usually are -- then this gives you at most 38 bits -- i.e. 2^38 hashes to
test -- to search (even a couple less if you know a priori which *brand* of
card it
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote:
Yes, encrypting indexed columns for example is a problem. But if you
limit yourself to encrypting sensitive information (I'm talking about
stuff like SIN, bank account numbers, data that serves as an index to
external databases and
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real
problem
| is the key handling (how to make sure the DBA can't get the key,
cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the
[EMAIL PROTECTED] writes:
I saw allot of requirements by security auditors that looked pretty
silly.
Must use 128-bit RSA encryption has to be the all-time favourite.
One I saw recently was a requirement for using X9.17 key management... in
SSL.
Peter.
One of my favourites was that PINs
Perry E. Metzger wrote:
Have a look, for example, at
http://www.americanexpress.com/
which encourages users to type in their credentials, in the clear,
into a form that came from lord knows where and sends the information
lord knows where. Spoof the site, and who would notice?
Every company
Steven M. Bellovin wrote:
The bigger issue, though, is more subtle: keeping track of the keys
is non-trivial. These need to be backed up, too, and kept separate
from (but synchronized with) the tapes. Worse yet, they need to be
kept secure. That may mean storing the keys with a different
Perry wrote:
In case you think the answer is regulation, by the way, let me note
that most of the regulatory pressure I've seen on security policy
results in people finding extremely well documented ways to do exactly
what the regulators ask, to no actual effect. This is generally
because the
On Wed, Jun 08, 2005 at 01:33:45PM -0400, [EMAIL PROTECTED] wrote:
|
| Ken Buchanan wrote:
| There are a number of small companies making products that can encrypt
| data in a storage infrastructure, including tape backups (full disclosure:
| I work for one of those companies). The solutions
2) The cost in question is so small as to be unmeasurable.
Yes, because key management is easy or free.
Also, reliability of encrypted backups is problematic: CBC modes render
a single fault destructive to the entire dataset. Counter mode is
sufficiently new that it's not supported by
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key management, but the
Ben Laurie writes:
Why is it bad for the page to be downloaded clear? What matters is the
destination is encrypted, surely?
Because the page you downloaded in the clear contains the https: URL
in the post method. How do you know that this is the right URL? If
you got the page in the clear, you
From: Ian G [EMAIL PROTECTED]
Sent: Jun 7, 2005 7:43 AM
To: John Kelsey [EMAIL PROTECTED]
Cc: Steve Furlong [EMAIL PROTECTED], cryptography@metzdowd.com
Subject: Re: Papers about Algorithm hiding ?
[My comment was that better crypto would never have prevented the
Choicepoint data leakage. --JMK
On Tuesday 07 June 2005 14:52, John Kelsey wrote:
From: Ian G [EMAIL PROTECTED]
Sent: Jun 7, 2005 7:43 AM
To: John Kelsey [EMAIL PROTECTED]
Cc: Steve Furlong [EMAIL PROTECTED], cryptography@metzdowd.com
Subject: Re: Papers about Algorithm hiding ?
[My comment was that better crypto would
On Tue, Jun 07, 2005 at 05:41:12PM +0100, Ian G wrote:
|
| The difficulty here is that there is what we might call
| the Choicepoint syndrome and then there is the
| specific facts about the actual Choicepoint heist.
| When I say Choicepoint I mean the former, and the
| great long list of
In message [EMAIL PROTECTED], Perry E. Metzger writes:
The truth is, the likely reason no one encrypted the data on the tapes
in transit was because no one thought to do it, or they were too lazy
to bother to make even the simplest effort, or both.
I don't completely agree. While I suspect
On Tue, Jun 07, 2005 at 07:48:22PM -0400, Perry E. Metzger wrote:
It happens because some idiot web designer thought it was a nice
look, and their security people are too ignorant or too powerless to
stop it, that's why.
It has nothing to do with cost. The largest non-bank card issuer in
Steven M. Bellovin wrote:
The bigger issue, though, is more subtle: keeping track of the keys is
non-trivial. These need to be backed up, too, and kept separate from
(but synchronized with) the tapes. Worse yet, they need to be kept
secure. That may mean storing the keys with a different
From: Ian G [EMAIL PROTECTED]
Sent: Jun 4, 2005 6:43 AM
To: Steve Furlong [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Subject: Re: Papers about Algorithm hiding ?
GPG is an application that could be delivered by default
in all free OSs. BSD is more or less installed automatically
with SSH
At 01:14 PM 6/3/2005, [EMAIL PROTECTED] wrote:
I think we are already in a state where practically everybody that has a
computer has crypto available, and it's not difficult to use it!
Of course they have it -
the problem is having crypto in a way that's not suspicious,
and suspicious is
On Thursday 02 June 2005 13:50, Steve Furlong wrote:
On 5/31/05, Ian G [EMAIL PROTECTED] wrote:
I don't agree with your conclusion that hiding algorithms
is a requirement. I think there is a much better direction:
spread more algorithms. If everyone is using crypto then
how can that be
On 6/3/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Another alternative is the cyphersaber type of thing, where you could just
implement your crypto-code on the fly, as needed.
Yes, I could, and have. Presumably you could. Ben Laurie probably
could blindfolded with both hands tied behind his
On 5/31/05, Ian G [EMAIL PROTECTED] wrote:
I don't agree with your conclusion that hiding algorithms
is a requirement. I think there is a much better direction:
spread more algorithms. If everyone is using crypto then
how can that be relevant to the case?
This is so, in the ideal. But if
Subject: Papers about Algorithm hiding ?
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.ht
m
http://news.com.com
-Original Message-
Hadmut Danisch wrote:
...
Plenty of research has been done about information hiding.
But this special court case requires algorithm hiding as a kind of
response. Do you know where to look for papers about this subject?
...
Here is the list that you can start
HD What about designing an algorithm good for encryption which someone
HD can not prove to be an encryption algorithm?
Hmmm, but to do that one needs to have a good definition of 'encryption
algorithm' and perhaps also some other apparently fundamental terms. But
we have none, I am afraid ... at
| 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
|
On Thursday 26 May 2005 22:51, Hadmut Danisch wrote:
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
37 matches
Mail list logo
