Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enclave: An Unpickable Lock

ominoushum.com

Post reply on HN
Print view View original

241–250 of 328 posts

Re: Enclave: An Unpickable Lock

#241

Post by mizzao »

swighton wrote: post #44

Interesting design. I made a lock a couple years ago that is quite similar in principle (though this design is different and has a couple nice improvements). https://youtu.be/_7vPNcnYWQ4 One of my main goals is to be an inspiration, though if it was based by my design I wish they’d credit it. Especially since they’re patenting it.

For others who might not have seen it, here's what the Lockpicking Lawyer had to say about that.

He picked a lock with the same concept by swighton (Stuff Made Here), but exploited a flaw that had nothing to do with the mechanism.

https://www.youtube.com/watch?v=Ecy1FBdCRbQ

I think one problem here is that the more complicated you make a locking mechanism, the more you suffer by increasing the attack surface with other potential flaws or just the lock being physically weaker (i.e. smashable).

Kinda like how the most advanced cryptography is usually broken because someone made an error in the complexity of implementing it.

Re: Enclave: An Unpickable Lock

#242

Post by mlyle »

franciscop wrote: post #98
harrisi wrote: post #70

Earlier quoted context omitted.

The interaction of engineering and "use" by the Lock Picking Lawyer ( https://youtu.be/Ecy1FBdCRbQ ) was fascinating - "use" here really meaning "exploiting". It's a problem many here are aware of, either by over-engineering things intended for use by non-engineers, or designing things to be used by customers when the designer isn't intimately familiar with the use. In this case it was sort of somewhere in between. I…

Def want to see Enclave's under Lock Picking Lawyer! If you make a "unpickable lock" you'd def want to send it to LPL, that's like the ultimate proof of how easy/hard it is to pick. The fact that there's no video, with how approachable LPL is and accepts random locks in his PO box, can only be seen as a red flag. Do it in the open, like Stuff Made Here!

> The fact that there's no video, with how approachable LPL is and accepts random locks in his PO box, can only be seen as a red flag.

He says he's going to make a small number of prototypes and send them to the locksport community. It's not a "red flag", it's just very early in his design cycle.

Re: Enclave: An Unpickable Lock

#243

Post by mannykannot »

espadrine wrote: post #147
dmoy wrote: post #141

Earlier quoted context omitted.

> don’t see how this patent has any legs to stand on. Well USPTO did move to first-to-file under Obama. Is there a patent filed before this one?

My understanding of MPEP 2126-2128[0] is that prior art published to a website can be disqualifying. I don’t like patents, because given the world population, any idea was had by someone that didn’t have the resources to file it. Publishing a timestamped design is, I believe, one of the least expensive ways to create prior art without creating patents. [0]: https://www.uspto.gov/web/offices/pac/mpep/s2128.html

If I am not mistaken, there have been many cases where prior art was available (and in some cases quite well known within the field) but did not come to the attention of the examiner (or the examiner did not recognize its relevance), and the patent was granted anyway. In fact, there was one such case on the HN top page today.

https://news.ycombinator.com/item?id=31881973

Once that happens, getting it revoked is no easy task.

Re: Enclave: An Unpickable Lock

#244

Post by D_Alex »

lrvick wrote: post #133

I am a reasonably capable lockpicker and lock collector with hundreds of locks of every mechanism I can get my hands on... and as LPL often demonstrates, the vast majority of them, particularly the move clever seeming designs, are actually easy to pick. I have one of the Enclave lock prototypes on my desk and can confirm the machining is brilliant and I have no idea how one could approach picking this. No feedback at…

>I have no idea how one could approach picking this

Not sure how well the lock is made but it may be possible to detect when pins 1 and 6 are in correct position - because the slider is "stiff against springing apart" at those pins, if you get what I mean. The key might turn a degree or so more if those pins are correct, which may be detectable.. That would be only 36 positions to check.

Likewise, pins 2 and 5 should produce slightly more resistance than pins 3 and 4, but the difference would not be quite as pronounced. But if the difference is detectable, then it could be a possible attack strategy.

Re: Enclave: An Unpickable Lock

#245

Post by pwg »

cvccvroomvroom wrote: post #204
harrisi wrote: post #70

Earlier quoted context omitted.

The interaction of engineering and "use" by the Lock Picking Lawyer ( https://youtu.be/Ecy1FBdCRbQ ) was fascinating - "use" here really meaning "exploiting". It's a problem many here are aware of, either by over-engineering things intended for use by non-engineers, or designing things to be used by customers when the designer isn't intimately familiar with the use. In this case it was sort of somewhere in between. I…

I can't be bothered to use YT anymore with all the ads. They're basically interactive, on-demand, corporate TV monetizing other people's content and nothing more. The world needs a co-op video sharing app and a microblogging app.

Just download the videos you want to watch:

https://github.com/yt-dlp/yt-dlp

The only "ads" you get will be the ones the video uploaders encode directly into the video itself. Plus you can watch using whatever playback software works best on your system, instead of the rather feature free JS player youtube provides.

Re: Enclave: An Unpickable Lock

#246

Post by D_Alex »

_alex_ wrote: post #216
rblatz wrote: post #176

Earlier quoted context omitted.

So looking at the lock’s YouTube video it may be susceptible to an attack where you set all the pins to their lowest, turn the key and then jolt the lock several times while continuing to turn the key.

you're describing a bump key! https://en.wikipedia.org/wiki/Lock_bumping

No, that won't work, because the pins cannot be bumped once the lock is partly turned.

Re: Enclave: An Unpickable Lock

#247

Post by necovek »

bryans wrote: post #157
necovek wrote: post #145

Earlier quoted context omitted.

I am not sure if I would call trying all combinations "picking s lock" — wouldn't adding a couple of pins simply make that infeasible again? You could also bring all 46k key variations and try them out, and you'll open it with 23k attempts on average, but that would not make the lock pickable if I was to talk about it. I have no clue about locks, but there's a difference between brute forcing a password and decryptin…

> I am not sure if I would call trying all combinations "picking s lock" Lockpicking is defined as opening a lock with an instrument other than the appropriate key. It is not defined by how many attempts it takes. Many of the most common lockpicking methods are nothing more than brute force, which are sometimes incredibly effective. They're also sometimes the opposite of effective, meaning they may take many thousand…

My point is that every single lock (or password) is susceptible to trying every key combination: the only protection against that is to increase the number of combinations available.

Sure, if a particular lock is more prone to brute-forcing due to its design than an average lock (eg. side channel attacks like timing attacks with passwords), one could surely qualify that as a pickable lock (or a "weak" password scheme).

So I am not saying that a brute-forceable lock is not pickable, but that those are independent since every lock is brute-forceable. Sure, devil is in the details, and what seems like brute forcing is sometimes something smarter, but only when you are able to reduce the problem space from the full set of combinations would I say you are picking a lock.

Again, maybe I am totally off base with regards to terminology as used in lock picking circles, but this is how I would differentiate between different approaches.

Re: Enclave: An Unpickable Lock

#248

Post by D_Alex »

scotty79 wrote: post #196
rblatz wrote: post #176

Earlier quoted context omitted.

So looking at the lock’s YouTube video it may be susceptible to an attack where you set all the pins to their lowest, turn the key and then jolt the lock several times while continuing to turn the key.

Compressing the springs by jolting the lock (hitting it with something?) might be very hard if springs are strong and pins are light.

Especially if the lock is mounted in a door.

Re: Enclave: An Unpickable Lock

#249

Post by chaostheory »

swighton wrote: post #44

Interesting design. I made a lock a couple years ago that is quite similar in principle (though this design is different and has a couple nice improvements). https://youtu.be/_7vPNcnYWQ4 One of my main goals is to be an inspiration, though if it was based by my design I wish they’d credit it. Especially since they’re patenting it.

Love your videos! Of course you’re on HN

Re: Enclave: An Unpickable Lock

#250

Post by tzs »

dmoy wrote: post #141
espadrine wrote: post #129

Earlier quoted context omitted.

It is even closer to the design I published a year ago: https://github.com/espadrine/lock-designs/blob/main/commitme... I don’t see how this patent has any legs to stand on.

> don’t see how this patent has any legs to stand on. Well USPTO did move to first-to-file under Obama. Is there a patent filed before this one?

First-to-file doesn't mean what I think you think it means.

Prior art, whether from another patent or from some other source, will still establish that the applicant is not an inventor and not eligible for a patent.

First-to-file (FTT) only differs from first-to-invent (FTI) when there is an "interference". That's when two or more separate parties are simultaneously applying for patents on the same invention.

Under FTI your priority date was the date you conceived the invention if you then worked diligently toward reducing the idea to practice up until you filed your patent application. If you stopped working diligently on reducing the idea to practice and then resumed it, the date you resumed became your new priority date.

What counts as a break in working toward reduction to practice sufficient to reset your priority date? How much documentation do you need to prove you were working continuously on it from your claimed priority date?

Figuring all that out can be expensive and time consuming and often gives results that seem wrong. It's almost random whether the priority date by this method actually matches who seems to morally most deserve the patent.

FTF gives priority to whoever files first. It doesn't produce any worse outcome than FTI and saves a lot of time and money for both the patent office and applicants.

Post reply on HN