[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 24 Jul 2012 23:20:46 +0400
From: Solar Designer <solar@...nwall.com>
To: Hank Leininger <hlein@...elogic.com>
Cc: defcon-2012-contest@...elogic.com, john-users@...ts.openwall.com
Subject: Re: Crack Me If You Can 2012
Hi Hank,
Thank you for the prompt response, and sorry that mine is a bit delayed.
Here's another thing I noticed: perhaps the specified contest start/end
time is actually in PDT timezone, not PST?
On Sun, Jul 22, 2012 at 06:18:08PM -0400, Hank Leininger wrote:
> Hi, thanks for the email, lots of good questions. I'll answer initially
> here, and we'll make things official with changes to the rule page in a
> bit. [ IOW this email is not the final or official word. ]
Please let us know when/if you update the rule page.
On Sun, Jul 22, 2012 at 05:25:41PM +0400, Solar Designer wrote:
> > "* You MUST NOT attempt to interfere with the efforts of another team.
> > * You MUST NOT attempt to steal passwords from or techniques/methods
> > used by another team."
> >
> > Does misinforming another team (or a member thereof) of our team's
> > progress, what techniques turned out to be (in)effective, etc. count as
> > "interferring" with their efforts or not? In other words, is this
> > permitted?
>
> So basically, social engineering attacks? We were mostly thinking of
> trying to DDoS other teams' channels of communication, infiltrating any
> _non-public_ forms of communication, hacking other teams' cracking
> systems or communications channels, etc.
>
> I would rather not try to enumerate all the things that wouldn't be OK,
> because then someone will figure out a corner case that we did not
> specify. Instead, I'll say "don't be a dick" - if something smells like
> deliberate bad sportsmanship, then it's a problem, and we will decide
> what to do about it.
What's good or bad sportsmanship depends on what's (not) allowed in the
rules. If social engineering attacks are allowed, they may become part
of the contest and a team's strategy, and they would be fair play. That
would be quite a different contest, though, so I understand that you may
not want to allow them - I just felt that this needed to be clarified.
Besides, if a team inadvertently discloses some valuable hint on a
public channel, how do they make up for the mistake? One way would be
to also use the channel to provide misinformation. ;-)
> Publishing deliberate misinformation, while it might be funny, would be
> likely to run afoul of the "Don't be a dick" spirit of the rules.
It depends. You know the spirit and you interpret the rules in a
certain way. Teams might interpret the rules differently. If one team
thinks that something is allowed - not only for them, but also for other
teams - they should reasonably make use of that, or they'd be giving
other teams an advantage.
> (Maybe we should literally include that in the rules...)
Yes, I think this needs to be clarified one way or the other.
> > "You MUST NOT switch teams during the contest--we will assume you stole
> > all the cracks from the team you left, or the team you join."
> >
> > Now this is a new restriction, and one that definitely needs to be
> > clarified. It is extremely ambiguous as written. What was the intent
> > here? Can you name specific examples from past contests (not
> > necessarily limited to past CMIYK) that would violate this rule?
> > And examples that would not violate it?
>
> Well, we found out about some cases of team-switching or merging (and
> had some complaints about it), and weren't happy, but hadn't had any
> rule against it.
>
> What we most want to avoid, is surprises that we'd consider unfair to
> the other players/teams. For instance, the #3 and #4 teams merging in
> the last hour in order to rocket at least one of them to #2 or #1. That
> would make the previous leaders feel cheated, and rightly so, I think.
It depends.
If allowed, this becomes part of the strategy and is fair play.
If not allowed, this encourages smaller teams to merge before contest
start - so in that sense it discourages smaller teams from directly
participating in the contest (contrary to what you're trying to achieve,
it seems). I am speaking in general, though. This might not apply to
the specific teams this year.
You ought to clarify this - and make sure teams are well-informed of
this new rule.
> I think if people want to, say, do their own solo/small team, to keep
> track of how say their special tools or techniques do, while also being
> a member of a larger team _all along_ that they feed cracks into but
> don't take cracks from, that would be OK, provided they let us know
> *early on*, and the larger team they're in also knows all along. (That
> has been the case sometimes, I know.)
This makes sense.
> > What about team mergers during contest - e.g., if teams currently ranked
> > 4 and 5 decide to merge and hopefully take 3rd place, moving the team
> > currently ranked 3rd down to the 4th place? Is this permitted? (Of
> > course, assuming that the teams choose which one will be the merged team
> > and submit both teams' cracks under that team before the contest ends.)
>
> So, according to my above, this would be the situation that would bother
> us most, team switches and/or mergers during the contest. We feel that
> situation is the least fair to the other players.
OK. I feel it would be fair if it were explicitly allowed and thus
expected by all, though.
> What if somebody tries to compete solo, but quickly realizes they didn't
> have enough time to devote to the contest and decides they want to join
> up with an existing team instead? I think we ought to allow that,
> rather than just forcing them to give up and walk away, which is no fun.
> Probably with a time limit on such a merger. I don't know exactly what
> that limit should be, but on the order of 12-18 hours into the 48 hour
> contest. I think we'd ask that someone considering that should email our
> human contact address to ask us to approve it.
OK, although I think this is unnecessarily complicated.
> I think I will take a modified version of your suggestion.
>
> a) Small teams that are also feeding their cracks into a larger team are
> allowed, as long as their situation is clear both to us and to the
> larger team.
> b) Only the highest-scoring of such merged teams is eligible.
Sounds fine.
I think the smaller vs. larger distinction is not necessary (and may
sometimes be difficult to determine) - it's sufficient to specify that
one team feeding cracks to another is allowed, but only the
highest-scoring of such merged teams is eligible.
Then it becomes trickier to disallow team mergers during the contest,
though - if you want to disallow these. Constant feeding starting early
on is allowed but feeding half way through the contest is not? That's a
bit weird. (I'd just allow all mergers, but it's your call.)
> Meanwhile:
> - small teams merging/joining others _early_ in the contest is generally
> OK, but requires approval (email us to say you want to do it).
> - "last-minute" sharing/mergers is still not allowed.
> - members switching from one team to another is still not allowed.
OK.
> So for your earlier example, if bartavelle and 16Crack both compete in
> the 2012 contest, they could also feed their cracks to john-users, as
> long as team john-users knows they are also competing on their own, and
> as long as they notify us early on in the contest. If john-users,
> bartavelle, and 16Crack then sweep the #1, #2, and #3 spots, only the
> team that got #1 would get a prize; the others would revert to the #4
> and #5 spots. (In fact we can probably capture this in the scoreboard,
> we will just flag known sub-teams as not being eligible.)
Makes sense.
In practice, though, some folks who would feed cracks to us are so
law-abiding that they may choose not to do it given the new rules, even
if you say it's "sort of OK".
In general, laws often hurt law-abiding citizens the most.
Thanks again,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
