Home opinion-and-analysis Open Sauce OpenBSD backdoor claims denied

Author's Opinion

The views in this column are those of the author and do not necessarily reflect the views of iTWire.

Have your say and comment below.

Two developers named as having played a role in creating backdoors for the FBI in the open cryptographic framework used in OpenBSD have denied they did so.


The claims were made by Gregory Perry, a former OpenBSD developer who now heads a company in Florida named GoVirtual Education; it offers VMWare training.

In an email to the head of the OpenBSD project, Theo de Raadt, Perry accused a couple of people by name of implementing the backdoors.

De Raadt posted the mail to the openbsd-tech mailing list.

A developer named Scott Lowe was one of those named by Perry; he was tracked down by Brian Profitt, a tech writer for ITWorld and former editor of LinuxToday.

Profitt wrote that he had encountered two people with this name and that both had denied any involvement.

A second person, named Jason L. Wright, posted to the same thread that De Raadt began, saying, in part: "I will state clearly that I did not add backdoors to the OpenBSD operating system or the OpenBSD crypto framework (OCF)."

In the same thread, Damien Miller, a Melbourne-based OpenSSH developer, detailed what he called a "few, obvious ways" in which plaintext or key material could be leaked.

Miller also pointed out that as US citizens or foreign citizens working in the US were never allowed to work on cryptographic code, direct interference in such code was unlikely.

"(OpenSSH and OpenBSD developer) Niels Provos used to make trips to Canada to develop OpenSSH for this reason," he wrote.

These restrictions are due to the US government's stance on the export of cryptographic code.

 

WEBINAR 7th May 11am - WOW 802.11

Learn how Ruckus Redefines High-Speed, High Capacity Wi-Fi with Industry’s First 802.11ac Wave 2 Access Point

THIS IS ONE NOT TO MISS SO REGISTER NOW

DON'T MISS OUT - REGISTER NOW!

FREE WHITEPAPER - RISKS OF MOVING DATABASES TO VMWARE

VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!

DOWNLOAD!

Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.

Connect