lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B741580.5080002@gmail.com>
Date: Thu, 11 Feb 2010 09:34:40 -0500
From: Nick Chernyy <nchernyy@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: SMS Banking

On 2/10/2010 2:56 PM, Craig S. Wright wrote:
> Tim,
> You stated “You are officially “on.” “ to my challenge.
>
> I am arranging a contract. An attorney has been arranged for both the
> contract and the escrow.  This will take a number of days. 
>
> The amount has upped and there are a couple other aspects, but the initial
> framework holds. Stop trying to weasel. 
>
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
> From: Thor (Hammer of God) [mailto:Thor@...merofgod.com] 
> Sent: Wednesday, 10 February 2010 3:59 PM
> To: craig.wright@...ormation-Defense.com; Valdis.Kletnieks@...edu
> Cc: pen-test@...urityfocus.com; 'full-disclosure';
> security-basics@...urityfocus.com
> Subject: RE: [Full-disclosure] SMS Banking
>
> Now you’re talking.  But first let’s work up an actual contract.  Neither of
> your components define anything.  When you say that you are going to predict
> “risk” with your  magic formula, do you mean if the software has
> vulnerabilities?   That it can be hacked, or will be hacked?  
>
> Be sure to define this properly and definitively – if you end up saying that
> a system has a 1% change of being hacked, and I (or my auditors) hack it,
> would you claim you were “right”?  I question if you can even define the
> parameters of this bet, much less apply your formulas, but we’ll see. 
>
> I also want to know what “scale” you plan to use.  So far, even though I’ve
> asked, you’ve not provided what the “answer” to your formula is, or how it
> will be applied.   I’m assuming, unless you are going to change your tune
> which I wouldn’t doubt, that you won’t look at the software code or threat
> models, but rather apply your formulas.  I further assume that the “loser”
> will be financially responsible for the “audits” done my way.
>
> I’m more than happy to take your money, and I look forward to doing so. 
>   Since one of your masters degrees is in law, I’m assuming you can clearly
> define the terms of the contract.    I will, of course, insist upon a
> contract, and I hope you won’t mind that I have my own attorney look it
> over.    I’m not immediately trusting of the competence of one with a
> doctorate degree and multiple masters degrees who can’t spell “technology”
> or “experience” correctly on his on-line CV.  
>
> You are officially “on.”  And I’m looking forward to it.
>
> t
>
>
>
> From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com] 
> Sent: Tuesday, February 09, 2010 7:41 PM
> To: Valdis.Kletnieks@...edu; Thor (Hammer of God)
> Cc: pen-test@...urityfocus.com; 'full-disclosure';
> security-basics@...urityfocus.com
> Subject: RE: [Full-disclosure] SMS Banking
>
> I have a simple answer to this. Forget the debate, rhetoric is not a
> scientific method of determining truth.
> “Thor” wants a challenge, let’s have one – a real one and not one based on
> verbalisations, abuse and unfounded assertions.
> I suggest two components;
> 1       A selection of software products are tested using both processes,
> that is I use a model for the risk of these products, and “Thor” can make up
> whatever guesses he wishes. We model (or “Thor” guesses, pulls from a
> hat...) the vulnerabilities over a time period. The number of bugs in
> software as well as the risk are to be presented as a monthly estimate. 
> 2       We model a few systems (say 50). We can use Honeypots (real systems
> set to log all activity without interference) run by an independent party to
> each of us. I use probabilistic models to calculate the risk. “Thor” does
> whatever he wants.
> Each of the predictions is published by all parties. The one who is most
> accurate wins. Fairly simple?
> I will even give a handicap to “Thor”, I will offer to predict within a 95%
> confidence interval and that for me to win, at least 90 of the 100 software
> products and 45 of the 50 systems have to lie within my predicted range that
> I calculate and release. “Thor” has to simply guess better than I do no
> matter how far out he is.
> I will put up $10,000 Au for my side. Let’s see if “Thor” has something real
> to offer.
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>   
Dr. Wright,
I have only now looked at the original post at
http://gse-compliance.blogspot.com/2010/02/modelling-risk.html and find
a few issues with the basic statistics. The core of the argument is that
the CDF of a Poisson distribution does not go to 0 as time goes to
infinity. The mathematical formulas are unreadable in their GIF format,
perhaps there is a PDF available, so I find these two general problems:

1.) This assumes a constant rate for the Poisson process, which is
generally a bad model for vulnerability discovery. I am more experienced
with hardware security, so I will use the iPhone as an example. It took
some months for the development of the initial jailbreak, however,
successive jailbreaks were released days after software updates once the
iPhone's internals were well understood. Part of the security of a
closed-source system is the lack of information about the system's
internals. Once an initial vulnerability is discovered, and exploited,
any new information would change the probability of successive
vulnerability discoveries.

2.) Your model does not account for software updates or patches. Any SMS
system likely has a group of developers which constantly operates to
improve performance and security. This again changes the Poisson rate as
vulnerabilities are constantly patched and new ones are potentially
introduced.

Finally, you do not mention anything about variance in your rate
constant or decay variable estimates. In statistics terminology, any
quantitative statements made using these formulas lack power. Until
these issues are addressed, I am not sure that this analysis is useful
outside of a very restrained MATLAB simulation.

-Nick

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ