Re: Gnu PG is more Safe ?
On Jul 23, 2013, at 9:01 PM, oxopz7@riseup.net wrote:
Hello everybody!
I hope all are fine, and doing well!
I'm good member :) I hope you will accept me!
Welcome to the list! It's good to see so many new members coming on board. I'm new myself.
I like to ask about GNU PG, if is more safe than other kind of software! that talks about Crypto ?
Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure. That doesn't mean it's perfect and has no errors. But they are much less likely to exist in GnuPG than in some other solutions; particularly proprietary ones.
I like to ask also about good resources in Crypto, specially about SSL/TLS?
One of the best ways to learn about tech topics is reading RFC's. The entire way SSL/TLS operates is detailed in an RFC. Read I'd and you will be infinately more informed. Unfortunately, I can't really recommend any good crypto list because I've not found many. To learn about FnuPG and practice, you might want to look at the PGPNET list. Another of interest might be Cryptography. Regards and Welcome! Anthony
Anthony Papillion <papillion@gmail.com> writes:
Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure.
That should actually say "because GnuPG is open source, people assume that someone else has extensively peer reviewed it and therefore assume that it's safe and secure". For example there was a long-standing RNG bug that was very obvious if you looked at the code, but was only discovered by chance when someone who was interested in the RNG happend to read through the code and thought "hmm, surely that can't be right". Having code that's open source doesn't help at all if no-one looks at it.
One of the best ways to learn about tech topics is reading RFC's. The entire way SSL/TLS operates is detailed in an RFC. Read I'd and you will be infinately more informed.
Argh, no. The best way to confuse someone is to get them to read an RFC. Find a good book on the topic, e.g. for SSL/TLS there's Eric Rescorla's "SSL and TLS: Designing and Building Secure Systems". Before that, read "Network Security: Private Communication in a Public World" by Kaufman et al. Peter.
On Jul 23, 2013, at 10:08 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Anthony Papillion <papillion@gmail.com> writes:
Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure.
That should actually say "because GnuPG is open source, people assume that someone else has extensively peer reviewed it and therefore assume that it's safe and secure". For example there was a long-standing RNG bug that was very obvious if you looked at the code, but was only discovered by chance when someone who was interested in the RNG happend to read through the code and thought "hmm, surely that can't be right". Having code that's open source doesn't help at all if no-one looks at it.
True. So perhaps we can say it is "less likely" to have glaring bugs than it's proprietary counterparts. Sure, bugs will be overlooked or outright missed in any project of size. But with more eyes comes a better chance of bugs and backdiors being caught.
One of the best ways to learn about tech topics is reading RFC's. The entire way SSL/TLS operates is detailed in an RFC. Read I'd and you will be infinately more informed.
Argh, no. The best way to confuse someone is to get them to read an RFC. Find a good book on the topic, e.g. for SSL/TLS there's Eric Rescorla's "SSL and TLS: Designing and Building Secure Systems". Before that, read "Network Security: Private Communication in a Public World" by Kaufman et al.
It depends on the RFC and how it's written. I've read many RFC's that were very informative and easy to understand. A well written book on the topic is always better, but you can almost always find what you need in the RFC. It may not be optimal but it's not horrible. Anthony
On 24. 7. 2013 5:20, Anthony Papillion wrote:
True. So perhaps we can say it is "less likely" to have glaring bugs than it's proprietary counterparts. Sure, bugs will be overlooked or outright missed in any project of size. But with more eyes comes a better chance of bugs and backdiors being caught.
There is a paper on discovering vulnerabilities in open source and proprietary software you might find interesting: Härtig, Hermann, Claude-Joachim Hamann, and Michael Roitzsch. "The Mathematics of Obscurity: On the Trustworthiness of Open Source." Workshop on the Economics of Information Security 2010. http://weis2010.econinfosec.org/papers/session6/weis2010_haertig.pdf Kind regards Martin
Martin Rublik <martin.rublik@gmail.com> writes:
There is a paper on discovering vulnerabilities in open source and proprietary software you might find interesting:
There's been a bunch of work done in this area, another one that springs to mind is Coverity's scan reports. The general conclusion from them is, unsurprisingly, that being open source doesn't magically make you more secure. You only find bugs (vulns) if someone looks for them, and a closed-source app that's actively analysed for vulns (because the vendor pays employees to do it) is going to be more secure than an open-source app that no-one looks at because they're not motivated to. In either case the ones with the highest motivation to look are the attackers. Peter.
Snarling disagreement, condescension and supplication, nectar and myrrh. Read books, quaintness from hell if not on SM in snippets. Inspired, the need to monetize crypto attacks rather than by "free cigarette sample" open source. That follows the well-paid bounty model of major software producers recently reported. Attackers build rep by hacks then convert to a business model, why this very list has successful graduates of this curriculum: if not extortion and exploits then by contracts, aka peacekeeping needing daily deposit of gash. It also follows the national intelligence model of grabbing open source material then classifying it as gov property sold back to the citizenry through the free market for extortionate security. Get some and copyright it. Cryptoanarchy is precisely this digital stash counterfeiting, RTF Bible by Rt Rev TCM. Tap his steel gate and die by his wildcats. Oh, and newbies are open source thieves working for OS spies, see the bible's classified Annex available by continuous automatic updates, not free to SOB TLAs running all possible crypto learning and hustling initiatives. This is WK fact, see frequent references in the archives, in the archives, oh, the archives will make you sagely numb. Need a numb sage lawyer to advise on your Crypto-AG racket? Stewart Baker is top of the sages ex-NSA, connected to all the others out to eat your baloney wich or hire you cheaply under life-wrecking NDA if a new immigrant still working in a cellar in PK. "Fuck cpunks to death." Is this still redacted here?
On Wed, Jul 24, 2013 at 07:31:20PM +1200, Peter Gutmann wrote:
unsurprisingly, that being open source doesn't magically make you more secure. You only find bugs (vulns) if someone looks for them, and a closed-source app that's actively analysed for vulns (because the vendor pays employees to do it) is going to be more secure than an open-source app that no-one looks at because they're not motivated to.
Of course open source isn't magic pixie dust, but neither is most commercial software very well analyzed. There are exceptions, but most commercial software that I have direct experience with is lacking the "active analysis" by people who are qualified and motivated to find bugs. -andy
No results about the last two books Peter! :'( What about these books: SSL TLS Essentials Securing the Web SSL and TLS Theory and Practice Implementing SSL TLS Using Cryptography and PKI Actually; I want to focus on the algorithms that are used on it. Not just know or implement and doing things with these protocols! Cheers to all, Best Regards,
Anthony Papillion <papillion@gmail.com> writes:
Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure.
That should actually say "because GnuPG is open source, people assume that someone else has extensively peer reviewed it and therefore assume that it's safe and secure". For example there was a long-standing RNG bug that was very obvious if you looked at the code, but was only discovered by chance when someone who was interested in the RNG happend to read through the code and thought "hmm, surely that can't be right". Having code that's open source doesn't help at all if no-one looks at it.
One of the best ways to learn about tech topics is reading RFC's. The entire way SSL/TLS operates is detailed in an RFC. Read I'd and you will be infinately more informed.
Argh, no. The best way to confuse someone is to get them to read an RFC. Find a good book on the topic, e.g. for SSL/TLS there's Eric Rescorla's "SSL and TLS: Designing and Building Secure Systems". Before that, read "Network Security: Private Communication in a Public World" by Kaufman et al.
Peter.
Because GnuPG is open source, it's been extensively peer reviewed and found safe and secure. That doesn't mean it's perfect and has no errors. But they are much less likely to exist in GnuPG than in some other solutions; particularly proprietary ones.
Are there more than 3 current OpenPGP tools? 1) GnuPG, GPL'ed open source, based on GnuPG's own libgcrypt family of libraries. Many many features, including NSA SuiteB support. Widely used in scripts, relied on by Thunderbird EnigMail, and other tools. 2) NetPGP, BSD'ed open source, depends on libOpenSSL, and it's own OpenPGP:SDK (C library). Basic features only, more like last pgpi.org PGP 2.x open source command line tool. Very few ports, besides NetBSD (NetPGP's sponsor). less peer review than GPG. No NSA SuiteB support (though libOpenSSL does support it). Someone needs to add SuiteB support, and a few more ports, support for opensource keyservers, and SuiteB, then it would be a nice option. 3) PGP product Symantec/PGPcorp. extremely expensive, closed source, patented keyserver tech, zero community review. Apparently a rich set of features for commercial enterprise use. If there are other open source OpenPGP tools besides GnuPG and NetPGP, that would be welcome news.
Blibbet <blibbet@gmail.com> writes:
If there are other open source OpenPGP tools besides GnuPG and NetPGP, that would be welcome news.
cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/index.html, been around for... well, longer than GPG has :-). Peter.
participants (7)
-
Andy Isaacson -
Anthony Papillion -
Blibbet -
John Young -
Martin Rublik -
oxopz7＠riseup.net -
Peter Gutmann