> From: tech-boun...@lists.lopsa.org [mailto:tech-boun...@lists.lopsa.org] > On Behalf Of Robert Hajime Lanning > > Why is the implementation in C#?
Initial implementation is C# because that's what was useful to us in development of desktop & mobile apps. Like it or not, you have to pay developers, so you have to focus on supporting the business first. Then if you're successful you can contribute more to the community which is not directly related to your business. The development direction for CBCrypt is to port to every language, and in particular, support websites and web browsers. Java and javascript come next. But we're not there yet. > I think tech and expected UX by the masses have outstripped what has > been designed here. You seems to have some preconceived notions about the UX. To address these concerns, I'll provide this response: We use CBCrypt in Synctuary. The UX in Synctuary goes like this: You have a username and password prompt. End of story. Behind the scenes, the Synctuary client authenticates and encrypts everything without exposing passwords or encryption keys to the server. There are no UX issues. Performance and responsiveness are excellent. > The base tech and reasoning sounds good, but little thought has been > done on the barrier to entry issue. This issue is going to be the user > experience. Is it going to take 30 seconds to login to a website from > your phone/tablet? You say "little thought" has been put into UX, and you made up the 30 second figure to exaggerate a point. Fortunately, you're wrong on both counts. ;-) Normally you design your system to use a workfactor of around 100ms to 200ms on the target platform. The rate-limiting function I was able to benchmark was pbkdf2, and the result is around 14,000 iterations. The performance of pbkdf2 on my i7 processor and my mobile device are not significantly different from each other - that is - around 14,000 iterations yields around 100ms to 200ms computation time on both my laptop and my phone. If this sounds surprising to you, because you think mobile devices have much less computation power than desktops/laptops/servers, you're partially right and partially wrong. The reality is, the clock speeds in the mobile devices are on-par with desktops and servers, but the instruction set and some other accelerators in the mobile devices are much more limited. As a result, some operations can be done on mobiles just as fast as desktops, while others perform dramatically different. In this case, what I benchmarked was pbkdf2, which is based on SH A1, and although I don't know the exact instructions that are exercised heavily in SHA1, I can say that in my benchmark, the mobile performance was perfectly acceptable, and on-par with the desktop. I would guess the mobile is a little slower, but in a dozen repeats of the benchmark the difference wasn't statistically clear or significant - which counts as a passing result for the mobile benchmark. Importantly, what takes 100ms on the laptop does NOT take 30 sec on the mobile. > BTW, I remember this whole discussion from last year. > https://lists.lopsa.org/pipermail/tech/2014-March/016206.html Cool. We first started work on it around Sep/Oct 2013, and I first spoke about this publicly around Nov 2013, code first published March 2014, first production deployment around March 2015. Crypto code and security changes require a lot of review and diligence. And like I said, we have to focus on being financially successful, so we have to contribute much less than full-time to CBCrypt advancement. At least for now. _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
