Re: It seems being in an explosion isn't enough...

2008-05-09 Thread mark seiden-via mac
i think the issue may simply devolve to  lower areal density in the  
old drives.

i.e. the bits are bigger.

does anyone know if they used encodings that were more tolerant of  
certain kinds of errors

in the past which are less common (and so, not worth doing) than now?


On May 9, 2008, at 1:44 PM, Ali, Saqib wrote:


  Edwards said the Seagate hard drive -- which was
  about eight years old in 2003 -- featured much
  greater fault tolerance and durability than current
  hard drives of similar capacity.


I am not so sure about this statement. The newer drives are far more
ruggedized and superior in constuction. For e.g. the newer EE25 are
designed to operate @
1) Operating temperatures of –30°C to 85°C
2) Operating altitudes from –1000 feet to 16,400 feet
3) Operating vibration up to 2.0 Gs
4) Long-duration (11 ms) shock capability of 150 Gs

where as the older ST9385AG:
1) Operating temperatures of 5° to 55°C (41° to 131°F)
2) Operating altitudes from –1,000 ft to 10,000 ft (–300 m to 3,000 m)
3) Operating vibration up to 0.5 Gs
4) shock capability of 100 Gs


Source:
http://www.seagate.com/docs/pdf/datasheet/disc/ds_ee25_2.pdf
http://www.seagate.com/support/disc/manuals/ata/9655pma.pdf

saqib
http://doctrina.wordpress.com/

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



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


Re: two-person login?

2008-01-29 Thread mark seiden-via mac

another term you might look for (used in physical security and
financial controls)  is  dual custody or sometimes double custody.

		(if you're searching, add  -child  or security for better search  
quality)


i don't see why the analogies are not apt.

one question is whether the two people can both perform their  
respective act independently

or whether they need to perform their act within a bounded time.

in the case of auditcon locks, for example, often used on the money  
safe part of atms:

http://www.kaba.co.uk/products/auditcon-2-series-model-252.asp

these features are called

Supervisor/Subordinate Mode
Allows access by a subordinate only after being enabled by a  
supervisory combination. Once enabled, a subordinate user has access  
to the lock during any valid opening time.
[for example, this would be used in a supermarket if a manager wants  
to allow a subordinate to open the safe the next morning]

or

Dual Custody
Two Person Integrity, which requires two users to open the lock.

the x-09 (approved for use in us top secret) has three modes:
A-single combination code
b-Dual combination mode which allows access only when two different  
three number combinations are dialed within 10 seconds of one another

c-Supervisory/subordinate mode

On Jan 28, 2008, at 2:56 PM, John Denker wrote:


Hi Folks --

I have been asked to opine on a system that requires a
two-person login.  Some AIX documents refer to this as
a common method of increasing login security
 http://www.redbooks.ibm.com/redbooks/pdfs/sg245962.pdf

However, I don't think it is very common;  I get only five hits
from
 http://www.google.com/search?q=two-person-login

By way of not-very-apt analogy:
-- I am aware of business checks that require two signatures;
-- I am aware that purchase orders are commonly signed by 
  two persons (the initiator and the approver);

-- I am aware of missile-launch procedures that require two
 persons using two keys;
-- I am aware of software development procedures where a patch
 is submitted (and signed) by one person, tested (and signed
 off) by another, and committed to the official repository by
 a third person.
-- et cetera.

However, it is important to note that the aforementioned examples
all share an important property, as we see from the following:
 *) The parties give their approval _after_ the semantics has
  been fully determined.  It would defeat all security if two
  signatures were attached to a blank check or a blank PO.
 *) As a related point, the approval is attached to a particular
  transaction.  The approver is not merely certifying that Joe
  is really Joe, and is generally allowed to write checks
  (mere identification);  the approver is certifying that this
  particular check is OK.
 *) To say the same thing another way, there is no pretexting.
  There is no pretext for turning the keys on the missile launcher
  unless you intend to launch a missile.  The semantics of the
  keys is clear.

We need to talk about threat models:
 a) The purveyors of the system in question don't have any clue
  as to what their threat model is.  I conjecture that they might
  be motivated by the non-apt analogies itemized above.
 b) In the system in question, there are myriad reasons why Joe
  would need to log in.  If Joe wanted to do something nefarious,
  it would take him less than a second to come up with a seemingly
  non-nefarious pretext.  When the approver approves Joe's login,
  the approver has no idea what the consequences of that approval
  will be.  The two-person login requires the approver to be
  present at login time, but does not require the approver to
  remain present, let alone take responsibility what Joe does
  after login.
 c) The only threat model I can come up with is the case where
  Joe's password has been compromised, and nobody else's has.
  Two-person login would provide an extra layer of security
  in this case.  This threat is real, but there are other ways
  of dealing with this threat (e.g. two-factor authentication)
  ... so this seems like quite a lame justification for the
  two-person login.
 d) Or have I overlooked something?



From the foregoing, you might conclude that the two-person login

system is worthless security theater ... but harmless security
theater, and therefore not worth worrying about either way.

But the plot thickens.  The purveyors have implemented two-person
login in a way that manifestly /reduces/ security.  Details
available on request.

So now I throw it open for discussion.  Is there any significant
value in two-person login?  That is, can you identify any threat
that is alleviated by two-person login, that is not more wisely
alleviated in some other way?

If so, is there any advice you can give on how to do this right?
Any DOs and DONTs?

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




Re: Lack of fraud reporting paths considered harmful.

2008-01-26 Thread mark seiden-via mac
yes, the reputation of/quality of reporters needs to be measured, and  
the reported information needs to be enough to

accomplish an auth or a card purchase.

the card issuer can then use a credible report as a hint to increase  
the level of attention to the reported cards.


it's in a merchant's interest to have high quality fraud detection  
because this report is
in association with an attempted purchase transaction and their report  
implies they
decline or refund the transaction they are turning down the revenue  
from that card,


if a bad guy wants to break into a merchant's site, i would welcome  
them to immediately report all the merchant's cards as stolen
rather than than stealing them and using them or waiting for the  
merchant to do so in a breach notice.




On Jan 25, 2008, at 3:11 PM, John Ioannidis wrote:


Perry E. Metzger wrote:

That's not practical. If you're a large online merchant, and your
automated systems are picking up lots of fraud, you want an automated
system for reporting it. Having a team of people on the phone 24x7
talking to your acquirer and reading them credit card numbers over  
the

phone, and then expecting the acquirer to do something with them when
they don't have an automated system either, is just not reasonable.


But how can the issuer know that the merchant's fraud detection  
systems work, for any value of work? This could just become one  
more avenue for denial of service, where a hacked online merchant  
suddenly reports millions of cards as compromised.  I'm sure there  
is some interesting work to be done here.


/ji

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



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