Re: [cryptography] Just how bad is OpenSSL ?
> I am wondering just how bad openssl is ? While one can find various software engineer faults, I think that main issue is not that it is "bad," it is that OpenSSL is written for cryptographic experts not standard software developers. The unfortunate thing is that most of the time the latter have no other choice but to use OpenSSL; in a perfect world they would be isolated from it by workflow-specific APIs that prevent them from shooting themselves in the foot too easily. Von On Oct 26, 2012, at 2:29 PM, John Case wrote: > > I was recently reading "the most dangerous code in the world" article at > stanford: > > https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html > > and found the hackernews discussion: > > http://news.ycombinator.com/item?id=4695350 > > (interesting discussion and argument about curl library and how often it is > badly deployed) > > And the hackernews discussion led me to "OpenSSL is written by monkeys": > > http://www.peereboom.us/assl/assl/html/openssl.html > > > So, given what is in the stanford report and then reading this rant about > openssl, I am wondering just how bad openssl is ? I've never had to > implement it or code with it, so I really have no idea. > > How long has it been "understood" that it's a mess (if it is indeed a mess) ? > How dangerous is it ? > > It looks like the rant was published in 2009 > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] can the German government read PGP and ssh traffic?
> "passwords are insecure, PKCs are secure, therefore anything
> that uses PKCs is magically made secure"
Well as you said, you have to look at what happens in the real world. I would
argue PKCs make things obscure, which buys you a fair amount of security until
some undetermined point in time (past or future) when an attacker gets serious
enough to understand what you are doing.
Von
On Jun 5, 2012, at 8:11 AM, Peter Gutmann wrote:
> Thierry Moreau writes:
>
>> Unless automated SSH sessions are needed (which is a different problem
>> space), the SSH session is directly controlled by a user. Then, the private
>> key is stored encrypted on long term storage (swap space vulnerability
>> remaining, admittedly) and in *plaintext*form*only*momentarily* for SSH
>> handshake computations following a decryption password entered by the user.
>
> ...except that a user study a few years back ("Inocilating SSH Against Address
> Harvesting") found that two thirds of all SSH private keys were stored in
> plaintext on disk. You need to look at what actually happens in practice, not
> what in theory should happen in an ideal world.
>
> In any case though you're completely missing the point of my argument (as did
> the previous poster), which is that a scary number of people follow the
> thinking that "passwords are insecure, PKCs are secure, therefore anything
> that uses PKCs is magically made secure" even when it's quite obviously not
> secure at all. This is magical thinking, not any kind of reasoned assessment
> of security.
>
> Peter.
> ___
> cryptography mailing list
> cryptography@randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] project cost of HSMs
On Apr 15, 2012, at 4:02 AM, ianG wrote: > Yep, that's the sort of info I was after - non-sticker price costs :) OK, > several to six months FTE or mm. That feels about right. > > I'm not sure about the outsourcing bit. What does it mean to preserve your > secrets in a HSM and then hand the HSM over to the care of someone else... ? > I'm not ruling it out, it's just that we seem to have a strange confluence of > contrary objectives :) Different model than you suggest - they own the CA (we never handle the HSM or CA keys). They delegate registration authority to us, so we approve requests and they issue the certificate (with a similar model for revocations). Obviously that's a very simple explanation of a complicated set of agreements. It makes sense for us because we are well situated to vet our users, hosts and services but not well situated to run a CA. And yes, the trade off is if the relationship falls apart, we build a new PKI since we don't own the CA. Von > > iang > > > On 11/04/12 00:12 AM, Von Welch wrote: >> Ian, >> >> I've led or been involved with several projects in academia that have used >> HSMs as a basis for a CA. I can't say I've done a cost analysis at the level >> of granularity you seem to be looking for, but I will say that at a >> high-level, the added personnel costs of integrating and maintaining an HSM >> have been the dominant factor in my experience. >> >> I estimate several-to-six (depending on the experience of the staff) >> additional FTE*months to understand the HSM (documentation always seems >> lacking) and get it working with our security libraries (OpenSSL typically). >> Maintenance is painful for a one-off since the HSM is this completely unique >> hardware and software system sitting in ones infrastructure, so that is a >> significant fraction of a person plus a small fraction of a second for >> backup (vacations, continuity, etc.). >> >> We did a second site redundant HSM-based CA once and it was a lengthy >> process mainly due to the staff there having to come up to speed on the HSM, >> again several FTE*months. >> >> I try to avoid this now and in my most recent project we're outsourcing >> this to a commercial vendor and it's my expectation the initial legal/policy >> issues with that route will be less painful than the HSM technical issues >> and then maintenance will be simpler. >> >> Von >> >> >> >> On Apr 10, 2012, at 2:26 AM, ianG wrote: >> >>> Does anyone have any estimates for the project cost of employing HSMs at a >>> single task? (e.g., protecting / deploying a single secret, not a network >>> of them.) >>> >>> I'm not looking for sticker prices but project costings, including: spare >>> devices, programming, work-throughs and transfers, documentation, testing >>> recovery paths, training, maintenance contracts, upgrades, etc. >>> >>> In comparison to the null project, not using them (e.g., using straight >>> servers in locked racks etc). >>> >>> tia, >>> >>> iang >>> ___ >>> cryptography mailing list >>> cryptography@randombit.net >>> http://lists.randombit.net/mailman/listinfo/cryptography >> > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] project cost of HSMs
Ian, I've led or been involved with several projects in academia that have used HSMs as a basis for a CA. I can't say I've done a cost analysis at the level of granularity you seem to be looking for, but I will say that at a high-level, the added personnel costs of integrating and maintaining an HSM have been the dominant factor in my experience. I estimate several-to-six (depending on the experience of the staff) additional FTE*months to understand the HSM (documentation always seems lacking) and get it working with our security libraries (OpenSSL typically). Maintenance is painful for a one-off since the HSM is this completely unique hardware and software system sitting in ones infrastructure, so that is a significant fraction of a person plus a small fraction of a second for backup (vacations, continuity, etc.). We did a second site redundant HSM-based CA once and it was a lengthy process mainly due to the staff there having to come up to speed on the HSM, again several FTE*months. I try to avoid this now and in my most recent project we're outsourcing this to a commercial vendor and it's my expectation the initial legal/policy issues with that route will be less painful than the HSM technical issues and then maintenance will be simpler. Von On Apr 10, 2012, at 2:26 AM, ianG wrote: > Does anyone have any estimates for the project cost of employing HSMs at a > single task? (e.g., protecting / deploying a single secret, not a network of > them.) > > I'm not looking for sticker prices but project costings, including: spare > devices, programming, work-throughs and transfers, documentation, testing > recovery paths, training, maintenance contracts, upgrades, etc. > > In comparison to the null project, not using them (e.g., using straight > servers in locked racks etc). > > tia, > > iang > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Password non-similarity?
> Bernie Cosell writes: >> On 31 Dec 2011 at 15:30, Steven Bellovin wrote: >>> Yes, ideally people would have a separate, strong password, changed >>> regularly for every site. >> >> This is the very question I was asking: *WHY* "changed regularly? What >> threat/vulnerability is addressed by regularly changing your password? I >> know that that's the standard party line [has been for decades and is >> even written into Virginia's laws!], but AFAICT it doesn't do much of >> anything other than encourage users to be *LESS* secure with their >> passwords. I was discussing this question of why "regularly force password changes" of a colleague who was responsible for security at a large University and his answer was you want to force undergraduates to change their passwords at a frequency that approximately matches the length of the average undergraduate romantic relationship. The implication being they tended to share the passwords with their boy/girlfriend and the forced change reduced the post-break up issues IT had to deal with. That anecdote aside, I agree this is a piece of advice that needs to go (along with password masking and other carry overs from the days of computers being rare and solely in centralized labs). Von On Dec 31, 2011, at 5:02 PM, Peter Gutmann wrote: > Bernie Cosell writes: >> On 31 Dec 2011 at 15:30, Steven Bellovin wrote: >>> Yes, ideally people would have a separate, strong password, changed >>> regularly for every site. >> >> This is the very question I was asking: *WHY* "changed regularly? What >> threat/vulnerability is addressed by regularly changing your password? I >> know that that's the standard party line [has been for decades and is >> even written into Virginia's laws!], but AFAICT it doesn't do much of >> anything other than encourage users to be *LESS* secure with their >> passwords. > > This requires an answer that's waaay too long to post here, I've made an > attempt (with lots of references to historical docs) in the chapter > "Passwords" in http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf (it's > easier to post the link than to post large extracts here, since the > discussion > is fairly in-depth). > > If there's anything I've missed or overlooked in that, let me know. > > Peter. > ___ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
