4 ms·

> I am not sure if I would call trying all combinations "picking s lock" [...] that would not make the lock pickable if I was to talk about it [...] but only wh

• necovek 4y ago
  >> So I am not saying that a brute-forceable lock is not pickable > You quite literally said it's not pickable and not even lockpicking at all I think you have a problem with me communicating using (formal) logic. If I say that A (lock is brute-forceable) is true, I am not making a statement on whether B (lock is pickable) is true: it could be either true or false. When I say that B is not true when A is, it means that B does not follow from A. As an admittedly non-expert, I find it useless to consider something that's a tautology (always true, lock is bruteforceable) as a special skill (lock-picking), and I complain of the terminology. IOW, it is my personal opinion that this is a useless terminology if it's used like that. > As far as I can determine, your opinion boils down to believing that successfully brute-forcing a lock with only 100 possible combinations does qualify as lockpicking But I explicitly clarified my position, and you even quote that twice: > 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. Which means that a lock with 100 combinations, and you try all 100 of them, you are not lock picking, but if you reduce that to trying out 50 combinations, then you are (again, I hope I don't have to highlight how this is my opinion of the terminology: I am repeatedly claiming I am no authority, but I can still have an opinion on language, along with the argument I am presenting). I apologize if my use of somewhat general language confuses you: my background in formal maths influences the way I communicate sometimes.
  • bryans 4y ago
    > I think you have a problem with me communicating using (formal) logic. The problem is that what you're saying is contradictory to itself. You're conveniently ignoring all of the flaws being pointed out, and instead reiterating the same argument ad nauseam, while also moving goal posts and morphing qualifiers as needed. > 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. Which means that a lock with 100 combinations, and you try all 100 of them, you are not lock picking, but if you reduce that to trying out 50 combinations, then you are The fundamental concept which you keep acknowledging but refuse to accept, is that brute force is a reduction of the problem space. In fact, it's a >99% guarantee to be reduced. Whereas the other lockpicking methods with a reduced space are not actually guaranteed to defeat the lock in a shorter amount of time, if at all. You even acknowledged in your first comment that brute-forcing a limited set will, on average, require half as many attempts. Since your qualification for being pickable is that the problem space is reduced by half, then brute-forcing meets your definition of lockpicking half of the time. At that point, it's irrefutably classifiable as lockpicking, with the understanding that other methods may be more (or less) effective. And you're still ignoring that the entire point of the lock being discussed is that traditional lockpicking methods wouldn't work. At all. Yet, when presented with an option to defeat the lock in less than 4 hours, your reaction was to repeatedly state that it doesn't even count as lockpicking. I don't know what else to say.
    • necovek 4y ago
      > And you're still ignoring that the entire point of the lock being discussed is that traditional lockpicking methods wouldn't work. I am not ignoring it: I was bringing a point on terminology, not on this particular lock or lock-picking methods. You seem to be unable to accept that people tend to and do use different terminology for same things, or same terminology for different things. > Yet, when presented with an option to defeat the lock in less than 4 hours, your reaction was to repeatedly state that it doesn't even count as lockpicking. I don't know what else to say. You need not say anything else, because I like to consider this a design idea, rather than a lock on a non-existent doors. What would be the effect on the time to "lockpick" exactly the same type of lock but with two more or double the number of pins (as an obvious counter measure)? Remember that this is a proof of concept lock and there are no doors it protects, so any actual implementation should be able to easily apply obvious extensions where higher security is needed. Again, it's not about this particular lock, but if there is an obvious scalability to the design, a lockpicking method only works if it scales linearly (like with regular pins, where you only test each pin individually). Yeah, I don't accept your terminology, and you don't accept mine (no matter how you try to stretch it how it being half on average is reducing the problem space when it's not: that's rudimentary math, and when you reduce the problem space in a smart way, it applies to each method: eg. testing individual pins, you'll find them on average in half the attempts...). I do struggle to understand why are you so keen to convince others how your use of terminology is the only acceptable use: it's ok to agree to disagree.