| >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 there
| was that they had a complete
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
| ...It is not that nobody ever thought of encrypting tapes, it is that there
| has been no uptake on the idea because the management overhead costs
| outweighed the perceived benefit. The big vendors didn't bother offering it
| because they didn't think they could make money, and the start-ups
> [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
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
| h
[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
Equifa
"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
[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 sev
> [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
> [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
> 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 database
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 Thursday 09 June 2005 16:41, you wrote:
> 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. Wit
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 a
[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.
--
[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
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 m
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
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, yo
> | 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 t
>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
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 soluti
"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 all involve appliances
> priced in the tens of thousands. The costs come
"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
> becau
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 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 s
There are large institution with 1000s of tape drives and 1,000,000
or more cartridges. Even simple solutions are huge to implement. This
is a non-trivial matter. The technical solutions are possible, there
are vendors out there that are already doing this. Getting from here
it there, even
a couple past posts (from jan. 1999) on the thread between information
security and risk management (in financial institutions, with stuff
about encryption, effects of exploits on corporate valuation ... even
includes some discussion of citi)
http://www.garlic.com/~lynn/aepay3.htm#riskm
http://
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 e
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
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 sus
Ian G <[EMAIL PROTECTED]> writes:
> No it's not rocket science - it's economic science.
> It makes no difference in whether the business is
> small or large - it is simply a question of costs. If
> it costs money to do it then it has to deliver a
> reward.
>
> In the case of the backup tapes ther
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 similar
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 abo
>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 woul
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 high
>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 a
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 ca
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 h
Well, everyone who has Windows on their machine (at least a Windows 95
updated version and up, I think) has at least Microsoft's crypto provider,
and MS CAPI to use it! Most broswers implement HTTPS, so you have crypto
there as well.
I think we are already in a state where practically everybody
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. Bu
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
> htt
| 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
|
http://news.com.com/Minnesota+court+takes+dim+view+of
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
> -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
PM
To: cryptography@metzdowd.com
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
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
http://news.com.com/Minnesota+court+takes+dim+view+of+encryption/2100-
47 matches
Mail list logo
