[Crypto-chi] Security Through Obscurity

[Mason Donahue]

Another data point: physical locks.
There was a huge outcry at the beginnings of locksport about "how dare
you point out how insecure these things are, you're helping the
criminals" followed by the observation that criminals already know how
to do this, and if more people understood how weak a lock was, they'd
plan contingencies around it.
Same thing with the Bic pen tubular lock kerfuffle for Kryptonite's bike
locks. (A Bic pen was the right diameter and a soft plastic, so it
basically made a perfect imprint on the pins and would work as a key.)

NYC's firemen's keys are an example: you can buy them
(http://nypost.com/2012/10/01/lock-away-these-nyc-keys/
https://www.schneier.com/blog/archives/2012/10/master_keys.html), but
the NYC master key is called a '2642' key because, well, that's the
bitting code. You can also just make one. People are(were?) arguing that
selling the key is some kind of horrible terrorist-helping exercise,
when all it takes is someone buying a standard Yale blank and a metal
file. The security of NYC elevators is based on people not knowing (or
not abusing the knowledge) that they all have a common master key that
you can buy from a hardware store key shop. Rather than fix the problem,
they asked the dude making them to stop. The news stories, most with
pictures of the keys in question for easy replication, did more to
expose the vulnerability of the design than a dude selling them on eBay
could.

Another data point: early electronic crypto designs.
The Geffe paper about using LFSRs as a keystream with an initial seed
was called 'How to Protect Data with Ciphers that are Really Hard to
Break,' but it turns out that they weren't (vulnerable to
known-plaintext, among other weaknesses).

(From a paper
(http://www.uobjournal.com/papers/uobj_paper_2014_51841529.pdf) about
that shift cipher:

The main goal of this paper is to find the initial values of every LFSR
in the system depending on the following information:
1. The length of every LFSR and its feedback function are known.
2. The CF is known.
3. The output sequence S (keystream) generated from the LFSRS is known,
or part of
it, practically, that means, a probable word attack being applied
(Schneier, 1997).)

Another data point: WWII ciphers.
Generally, people who do this for a living learned about it during WWII
with Enigma, etc. The idea is that if your cryptosystem assumes that the
details of the cryptosystem must be unknown in order for it to be
secure, it isn't -- Enigma was broken in part because of people
successfully recovering an intact machine and reverse-engineering it,
though the Germans' use of a key per day instead of a key per message
certainly made things easier
(http://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma).
Modern systems are designed so that the keyspace required to search,
even with full knowledge of the design of the system, is so large as to
be infeasible precisely because of things like this.

--Mason

On 2/18/15 10:28 PM, Dan Massoglia wrote:
> Thx both. Another application I think is some of the wi-fi or bluetooth
> components being added to cars, I think in some cases for unlocking (?).
> I remember reading about that a while ago. I'm interested in this in
> part to try to bridge a gap between privacy people and security folks.
> When some privacy scholars say "obscurity" they act as if the words stay
> in a privacy context (which is supposed to exist in the abstract)
> without security comment or consideration. I thought the disconnect
> might form connections. 
> 
> On Wed, Feb 18, 2015 at 10:25 PM, Peter Baumgarten
> <me at peter-baumgarten.com <mailto:me at peter-baumgarten.com>> wrote:
> 
>     A good example I can think of is wifi. Instead of using something like
>     WPA2 to secure an access point one can instead to just not broadcast the
>     SSID. The wifi network will not show up on a list of networks to connect
>     to but one can just manually enter in the SSID and then they can
>     connect. I do not if that helps you Dan, but it is the example I think
>     of when I hear security through/by obscurity and that it is bad.
> 
>     On Wed, 2015-02-18 at 22:18 -0600, brian wrote:
>     > I really don't know any good examples, though, I was able to find this
>     > techdirt article from last year about healthcare.gov
>     <http://healthcare.gov>.
>     >
>     >
>     https://www.techdirt.com/articles/20140820/15163928269/white-house-going-with-security-obscurity-as-excuse-refusing-to-release-healthcaregov-security-details.shtml
>     >
>     > Hope that helps you start the search.
>     >
>     > -Brian
>     >
>     > On 02/15/2015 03:58 PM, Dan Massoglia wrote:
>     >
>     > > Hey CP Ppl,
>     > >
>     > >
>     > > Does anyone have good information--preferably academic for what I'm
>     > > doing right now but security blogs or something cool too--about
>     > > Security through obscurity. We touched on it briefly at CryptoParty.
>     > > H8 sending out this ask without more but I'm at a loss for starting
>     > > on the security stuff sometimes. XO thanks
>     > >
>     > >
>     > > Dan
>     > >
>     > >
>     > > _______________________________________________
>     > > cryptoparty-chi mailing list
>     > > cryptoparty-chi at groups.sshchicago.org
>     <mailto:cryptoparty-chi at groups.sshchicago.org>
>     > > http://groups.sshchicago.org/listinfo/cryptoparty-chi
>     >
>     > _______________________________________________
>     > cryptoparty-chi mailing list
>     > cryptoparty-chi at groups.sshchicago.org
>     <mailto:cryptoparty-chi at groups.sshchicago.org>
>     > http://groups.sshchicago.org/listinfo/cryptoparty-chi
> 
> 
>     _______________________________________________
>     cryptoparty-chi mailing list
>     cryptoparty-chi at groups.sshchicago.org
>     <mailto:cryptoparty-chi at groups.sshchicago.org>
>     http://groups.sshchicago.org/listinfo/cryptoparty-chi
> 
> 
> 
> 
> _______________________________________________
> cryptoparty-chi mailing list
> cryptoparty-chi at groups.sshchicago.org
> http://groups.sshchicago.org/listinfo/cryptoparty-chi
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://groups.sshchicago.org/pipermail/cryptoparty-chi/attachments/20150219/d5275f04/attachment.sig>