Hifn policy on documentation
Hank Cohen
There has been some discussion of late on this list about Hifn's policy
with respect to releasing documentation to the general public. That
discussion lead to a great deal of uninformed speculation and
unflattering statement's about Hifn's unfriendliness towards the open
source community. I would like to set the record straight.
The simple fact is that anyone who wants access to Hifn's documentation
need only log on to our extranet site (http://extranet.hifn.com/home/)
to download as much as they like. This is true of the 795x Algorithm
accelerator chips and the 7855 and 8155 HIPP chips. Some more
restrictions may apply to our NP and flow through part documents.
Specifically the documentation for 7954, 7955 and 7956 is available.
The other chips that are supported by the Open BSD Crypto drivers
hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
and 7854) are legacy parts that are not recommended for new designs.
The driver will also work for 7954 even though that is not listed.
This does represent some liberalization of access in recent months.
Hifn is always monitoring its policy with respect to the confidentiality
of documentation and other business information. Some information will
probably always require a non-disclosure agreement. Information that
falls into that category is generally of a sensitive competitive nature,
contains trade secrets or is related to unanounced or unreleased
products.
Software licenses are generally restricted in the disclosure or source
code reproduction rights. Hifn reserves the right to keep our source
code proprietary. This should not affect the hifn(4) driver since that
driver is programmed directly to the hardware and does not use Hifn's
enablement software library.
Registration at our extranet is required along with an email address
that can be confirmed. We cannot support anonymous FTP or http
downloads. The reason for this is that we are required by the
conditions of our US export licenses to know who and where our customers
are. If anyone objects to registration then we could not sell them
chips anyway so it does not seem an unreasonable restriction to us.
I hope that this clears the air.
Best regards,
Hank Cohen
Product Line Manager
Hifn Inc.
750 University Ave
Los Gatos Ca. 95032
408-399-3593
Theo de Raadt
>with respect to releasing documentation to the general public. That
>discussion lead to a great deal of uninformed speculation and
>unflattering statement's about Hifn's unfriendliness towards the open
>source community. I would like to set the record straight.
>
>The simple fact is that anyone who wants access to Hifn's documentation
>need only log on to our extranet site (http://extranet.hifn.com/home/)
>to download as much as they like.
That URL is not a place where you can download data sheets. That is a
registration site that requires anyone who wants data sheets to enter
approximately 50 personal questions.
I can get documentation for pretty much 99% of the chips in the
industry without supplying any private information. I don't TRUST you
to keep my personal data private.
>Specifically the documentation for 7954, 7955 and 7956 is available.
>The other chips that are supported by the Open BSD Crypto drivers
>hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
>and 7854) are legacy parts that are not recommended for new designs.
>The driver will also work for 7954 even though that is not listed.
All of this is irrelevant. You require people to register. Do you
understand what you are asking people to do? You are saying "Please
give us all your private information, and then use the data sheets to
write code that will help sell our product".
>This does represent some liberalization of access in recent months.
No it does not. 8 years ago all the above data sheets were fully available
for download without any registration. Then about 5 years ago hifn closed
up completely, and documentation was totally unavailable. About 2 years ago
hifn went to this new model of "answer 50 personal questions".
"50 personal questions" is not open access. Please don't lie about it.
Other crypto chip vendors make their data much more easily available.
>Hifn is always monitoring its policy with respect to the confidentiality
>of documentation and other business information.
No, hifn is not monitoring the effects of their policy at all. Over
the last few years I have had extensive email conversations with hifn
employees (including you) on this issue, and absolutely nothing has
changed. You still think it is OK to get this personal information
from people. You tried to pacify me in private mail.
>Some information will
>probably always require a non-disclosure agreement. Information that
>falls into that category is generally of a sensitive competitive nature,
>contains trade secrets or is related to unanounced or unreleased
>products.
But we don't care about that information. We simply care about completely
unfettered access to data sheets that were freely available without registration
8 years ago.
>Software licenses are generally restricted in the disclosure or source
>code reproduction rights. Hifn reserves the right to keep our source
>code proprietary. This should not affect the hifn(4) driver since that
>driver is programmed directly to the hardware and does not use Hifn's
>enablement software library.
The only person talking about hifn's proprietary code is you. If you showed
it to us, we would not bother looking at it.
>Registration at our extranet is required along with an email address
>that can be confirmed. We cannot support anonymous FTP or http
>downloads. The reason for this is that we are required by the
>conditions of our US export licenses to know who and where our customers
>are. If anyone objects to registration then we could not sell them
>chips anyway so it does not seem an unreasonable restriction to us.
So the personal information you ask for in the registration process
will be given to the US government if they ask? Without court
documents demanding the information?
We are not your customers. YOU ARE OUR CUSTOMER. Our driver sells
your chips.
I know that our hifn driver has some problems. But because I cannot
get data sheets without giving you private information, I will not
spend even one moment more of my time to improve support for your
products. Jason and I spent a lot of time writing that code in the
past, but because your policies are privacy invasive towards us, and
thus completely thankless for the sales that we have given you in the
past -- we will not spend any more time on your crummy products.
And if you continue baiting me, I will delete the driver from our
source tree.
I stand by my statement that HIFN is not open.
sebastia...@jpberlin.de
>that can be confirmed. We cannot support anonymous FTP or http
>downloads. The reason for this is that we are required by the
>conditions of our US export licenses to know who and where our customers
>are. If anyone objects to registration then we could not sell them
>chips anyway so it does not seem an unreasonable restriction to us.
>
I would say: Bullshit...
Docs are "not" interesting for the MOST customers and not everybody who
reads the DOC is/or will become a Customer...
So providing them via Torrent, anonymous FTP or HTTP WITHOUT Registration
is possible for technical documentation.
Otherwise most universities in the US shouldn`t provide ANY documentation
(f.e. for any science project) either because they would have to care that
the peoples who read it are "customers" (so, students..).
I think you don`t understand the law you`ve mentioned correctly *my oppinion*
Anyway.. I hope Theo will write a little statement if that policy is
accaptable or not. Because such stuff influence my [hardware] decissions
directly..
Kind regards,
Sebastian
--
Don't buy anything from YeongYang.
Their Computercases are expensiv, they WTX-powersuplies start burning and
their support refuse any RMA even there's still some warenty.
Wijnand Wiersma
> Folks,
> There has been some discussion of late on this list about Hifn's policy
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
If you guys would stop talking out of your ass and spend your time
usefull (read: releasing FREE docs) you would see a increase of sales.
Wijnand
Constantine A. Murenin
> >The simple fact is that anyone who wants access to Hifn's documentation
> >need only log on to our extranet site (http://extranet.hifn.com/home/)
> >to download as much as they like.
>
> That URL is not a place where you can download data sheets. That is a
> registration site that requires anyone who wants data sheets to enter
> approximately 50 personal questions.
>
> I can get documentation for pretty much 99% of the chips in the
> industry without supplying any private information. I don't TRUST you
> to keep my personal data private.
As soon as one submits one's private information to Hifn, the
submitted data indeed no longer could be considered private. Look at
Hifn's HTML on the registration page:
<form action="http://extranet.hifn.com/home/anonymous/Default.asp"
method="post" name="userEdit" onSubmit="return validate(this);">
Is Hifn running low on supplies of cryptography hardware accelerators?
Or do these accelerators no longer work in recent operating systems
due to the lack of documentation?
Spruell, Darren-Perot
> Hifn's policy
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
I'm not sure the explanation sets anything *straight*. Hifn wishes to try to
open things up to be what they think is open enough for the open source
community to use, but they can't commit to do it right. Is Hifn "open" or
not? There is no "mostly open" or "kind of open" or "open under conditions A
B and C, and be sure to give us personal information."
> Software licenses are generally restricted in the disclosure or source
> code reproduction rights. Hifn reserves the right to keep our source
> code proprietary. This should not affect the hifn(4) driver
> since that driver is programmed directly to the hardware and does not
> use Hifn's enablement software library.
Software license? Code? You, like many vendors before you, make the mistake
of thinking that it is your source code that is wanted.
NO ONE WANTS YOUR SOURCES.
Specifications and documentation on how to interface with the hardware is
what is useful.
> Registration at our extranet is required along with an email address
> that can be confirmed. We cannot support anonymous FTP or http
> downloads. The reason for this is that we are required by the
> conditions of our US export licenses to know who and where
> our customers
> are. If anyone objects to registration then we could not sell them
> chips anyway so it does not seem an unreasonable restriction to us.
Weak. Docs and specifications != product.
Look. I am an example of somebody who purchased a Hifn product because at
the time I had some idea that the card would be well supported by the OS
that I would use it in. I've since lost that warm fuzzy. If the required
documentation can't be opened up, correctly, to the developers who would
write OS drivers for it, then I have no need to buy more (or even continue
using my existing half-supported card.)
I am an example of someone who could very well no longer purchase Hifn, nor
recommend that others purchase it for their own use, based on the fact that
my OS vendors of choice cannot adequately support it. I have other choices.
DS
Daniel Ouellet
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
For me it goes like this.
I use OpenBSD because it is stable and secure and well documented. I
don't need to register to read the wonderful man page and know how it
work and what's supported or not.
Adaptec got substantial sale drop last year and don't take my word for
it. Just look at the public results they need to release for the stock
market. They don't respect their possible users to make the
documentations available to great developers to make sure their hardware
works well on my OS of choice that is NOT Microsoft thank you!
The results, simple, I have no more Adaptec what so ever in my business,
NONE and trust me, I do have plenty of servers. See I have the choice
like may here to buy of recommend hardware we see as good and well
supported. I wouldn't recommend to any of my customers any hardware that
is not working properly because a company do not see the light and
restrict my choice by not allowing their chips to be well supported, so
I go else where to get what I need and yes, I do look at specs and buy
what I see as good and supported for me.
Hifn's is not on my list and join the same dead beat, not look at list
as Adaptec did.
See, it's great out there, we have choice to pick what we want to use
and my choice is to pick well supported hardware by MY OS of choice and
the well supported come to no price to you what so ever, other then
providing a place to download documentation to write good drivers for
your hardware.
You don't even have to write the code, even the cost of distributing
your well written drive ( if it even come to that) is not even yours!
So, I will return that to you and say, yes, "That discussion lead to a
great deal of uninformed speculation..." you try to tell people that you
respect their choice and you think they are allow to make their own
choice. I guess not.
Just learn from other mistakes and wins. Hardware buy goes to well open
hardware makers and looks like most of them are not from the US these
days, but they do see me as a valuable customers and they do want me to
have well working servers as they make sure their product is well
supported on my choice of hardware, not by writing BLOB, but by
providing documentations and let the one that know best how to support
their hardware do it on my OS of choice!
Do you understand what I am saying and trying to make you understand!?
And the bottom line is simple.
If Theo said "I don't TRUST you to keep my personal data private.", nor
do I. And as express to you, "We are not your customers. YOU ARE OUR
CUSTOMER.". So may be it's time you understand this and bring it up the
food chain in your business too!
Also, "And if you continue baiting me, I will delete the driver from our
source tree.", I wouldn't push it really. He did remove Adaptec from
OpenBSD last year and that was great as I didn't even have to question
if it was working well or not. It wasn't there, so no time waisting to
even try!
So, you want sales, just make the documentation !!!FREELY!!! available
and you would be surprise of what it does, plus you really have nothing
to loose! It doesn't cost you anything!
So, instead of hiring many more sales guys, or even PR guys to preach
the good of Hifn, let us do it fro you! How, well simple...
Open the documentation and then watch the list where everyone ready it
and see your chips working well on OpenBSD and then working well on ALL
other project over time!
I think you forget the most important things here. All Open Source
project do exchange with each other, some more then others, but they all
know what they other is doing!
Do the right thing and see everyone looks favorably to you in the end!
ISn't it what you spend lots of money in marketing to have users look
favorably to your chips so they use them?
Plus see this as an improvement, you increase your sales and you reduce
your costs!
Yes you do. No more needs to have servers keeping all that private
informations, and people looks at it and some more classifying it, and
some more communicating it to others, etc.
See, in the end, that increase your profit from day one!
Don't you like it?
Best,
Daniel
PS: I wish you the best in your future, what ever your choice might be.
Your call if that's going to be UP or DOWN.
Breen Ouellette
> I hope that this clears the air.
>
>
I was hopeful too, at the beginning of your message. As I neared the end
I was becoming skeptical, and by the time I clicked through to the
registration page I was fairly certain where this was heading. Several
posts later and it looks like I was right. I'm not the only person who
puts a great deal of value on personal data. Your company's personnel
seems to do so as well - I have tried fairly hard over the last week to
find contact information for your executives with no success. Hmmm,
imagine that!
I think that you may have misunderstood your target market, or at least
a portion of it. Users of OpenBSD tend to be the most cynical type of
person you are going to encounter. Many of us have gravitated towards
OpenBSD because we have been burnt in the past. We tend to guard our
data jealously. I haven't input my personal data on a website request
form for years, and I am not about to start. And I'm nowhere near as
hardcore as some of the people here. We have good reason not to trust
corporations - look at Enron. If shareholders cannot trust their
executives to fulfill the highest duty of a corporation - to maximize
shareholder profit - then how can we trust any company (which we do not
even have a financial interest in) to protect personal data which we
supply? We might as well be done with it and just post it to a website
for all the world to see.
Why this should matter to you is that we (OpenBSD users) drive sales of
your product. Hifn, on the other hand, does not drive sales of OpenBSD.
The dynamic of this relationship puts the onus on Hifn to cater to
OpenBSD's requirements if Hifn wishes to continue to benefit from the
relationship. OpenBSD requires unrestricted access to documentation,
which doesn't create a conflict with the export controls of the USA.
Theo will pull Hifn from the source tree if push comes to shove, and at
this point I could not care less. My Soekris vpn1411 is sitting on the
shelf next to my machine rather than inside of it. This is due to the
fact that it does not work the way it should. I would prefer to see
something good come of all of this, but if I have to trash my vpn1411
then it really doesn't make the situation any worse than it already is.
At least for me. It will definitely make it worse for Hifn.
If this situation does not resolve itself for the better then I will not
buy any further Hifn technology. But it gets even worse: I will not
recommend Hifn technology. In fact, I will speak very openly and very
negatively about the company and their products. This might not seem
like a big loss until you look deeper at who I know. My friends all work
in the IT industry. We talk about work all the time. Several of them
work for the federal and provincial governments and crown corporations
of Canada. They will certainly be seeing Hifn products in a new light.
One of them works for one of Canada's largest cities in the emergency
preparedness department. These guys take their security seriously
because they are on the front line of terrorism prevention. He will
definitely listen with great interest to what I have to say about Hifn,
and he will be sure to pass it up the chain. My wife works for one of
the big four global accounting firms. The national IT personnel will
hear all about Hifn next month at the company BBQ. My uncle owns several
oil and mining companies in Canada. My other uncle was in the military
and is well connected. Other relatives and friends work in government,
law, accounting, and engineering all across the country. The subject of
Hifn is likely to come up the next time I see each of them, as well.
Now multiply my contacts by the number of OpenBSD users who take this
stuff seriously (which just so happens to be the majority of them). It's
not a pretty picture.
I'm behind Theo 100%. The average person might consider him to be
over-reacting. I would counter that the average person will never be
involved in the purchase of a Hifn product. I strongly suggest that you
consider who you are about to alienate before you go and do it. There is
still an opportunity to make this into a positive situation for Hifn and
OpenBSD.
Breen Ouellette
Raja Subramanian
> I'm behind Theo 100%. The average person might consider him to be
> over-reacting. I would counter that the average person will never be
> involved in the purchase of a Hifn product.
Adding to your statement: I would be what you call "the average
person", and heaven forbid, I would never purchase any hardware that
the OpenBSD Gods did not bless. The simple reason behind it
is that I'm totally reliant on the OpenBSD developers for support and
whatever is good for them is the only thing that's good for me.
- Raja
Michael Scheliga
> From: owner...@openbsd.org [mailto:owner...@openbsd.org] On Behalf
Of
> Hank Cohen
> Sent: Monday, June 12, 2006 9:10 PM
> To: mi...@openbsd.org
> Subject: Hifn policy on documentation
>
> Folks,
> There has been some discussion of late on this list about Hifn's
policy
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
Mr. Cohen,
Perhaps you can talk to your legal counsel and actually break out the
documentation needed for these open source drivers into a separate and
truly open to the "general public" anonymous download site. I doubt
that the documentation that is being requested by developers is putting
you in violation of US Export Regulations. Your customer's locations
can be tracked through the distribution network of your chips and
devices that you already have in place. OpenBSD is not selling,
reselling, or modifying your products. Nor is OpenBSD asking to
download drivers or other source code that you may provide to others. I
understand it's very easy these days for attorneys to just say put
everything behind your registration only access extranet to be safe.
This is not acceptable and, in my opinion, is not open to the general
public like you stated.
It might take some effort on your part and that of your legal counsel
and compliance officers to keep the open source community happy and the
US Government off your back, but I think you'll find it will be worth it
in the end. You obviously care how the people reading this list
perceive your company and products or you wouldn't have written that
letter; now please take it a step further in the right direction.
Regards,
Michael Scheliga
Marc Balmer
> truly open to the "general public" anonymous download site. I doubt
> that the documentation that is being requested by developers is putting
> you in violation of US Export Regulations. Your customer's locations
I live in Switzerland. Do I give a fuckin' rats ass for US Export
Regulations?
Dag Richards
Not care about US Export Regs?
But that just means you want the terrorists to win.
After all our President is your President right?
Sleep, Consume, Follow Orders. It's the American way.
Marcus Watts
> Date: Wed, 14 Jun 2006 00:22:12 +0200
> From: Marc Balmer <ma...@msys.ch>
> To: Michael Scheliga <Mi...@scheliga.com>
> Cc: Hank Cohen <hco...@hifn.com>, mi...@openbsd.org
> Subject: Re: Hifn policy on documentation
>
> * Michael Scheliga wrote:
> > truly open to the "general public" anonymous download site. I doubt
> > that the documentation that is being requested by developers is putting
> > you in violation of US Export Regulations. Your customer's locations
>
> I live in Switzerland. Do I give a fuckin' rats ass for US Export
> Regulations?
>
>
Clearly you don't. The vendor probably does.
[ I do know somebody who once seriously inquired into the procedure
to send in partial dead rat corpses to city hall. Seems the
state had a bounty program on the books from a century ago ... ]
In this case, the vendor appears to be talking about documentation,
which means they're actually confused. EAR covers chips but not
documentation. By US law they *have* to care about the chips.
Otherwise they're not in business. However the same law and a bunch of
court cases also makes a big thing about "free speech". For quite a
number of years, when cryptography was considered a munition and not
allowed to be exported without special license, people were writing
books and talking about cryptography almost entirely without problems.
Somebody needs to point this out to them; there's simply no defensible
US export legal reason for them to make people fill out web forms of
any form to acquire human readable documentation.
If the purpose of their web registration was to satisfy US export
purposes, it would still be different. Such a form would mainly be
concerned with issues like "where do you live" - "can you prove you are
a US citizen" - and nothing more. The MIT folks distributed kerberos
source via http with just such a registration system for a number of
years.
If they're asking 50 nosey personal questions, that's not US export
law. That's business accounting and marketing think, 100% (or possibly
a *really* bad lawyer.) They want to know where to send the next load
of junk mail so they can spend their advertising dollars "most
effectively". They may want to resell that information to other people
in similar businesses. Their sales people want to know if you call
with questions after that whether you're going to buy enough of their
product to make it worth their time to answer your questions. Maybe
they're imagining they can reduce product liability claims - although I
don't know of very many product liability cases that were won by
failing to disclose problems. Seems like they're more likely to
succeed at reducing product liability by reducing customer interest and
usage. It's conceivable they think their competitors are actually
stupid enough that this form will stop them from learning about what
they're doing or coming up with better ways to do it. In any event,
however justifiable they think they are in their business practices, it
still stinks, and it bodes ill for their long-term business health.
I wish their competition the best of luck.
-Marcus Watts
Michael Scheliga
From: Michael Scheliga
Sent: Tuesday, June 13, 2006 4:21 PM
To: 'Dag Richards'
Subject: RE: Hifn policy on documentation
> -----Original Message-----
> From: owner...@openbsd.org [mailto:owner...@openbsd.org] On Behalf
Of
> Dag Richards
> Sent: Tuesday, June 13, 2006 3:49 PM
> To: mi...@openbsd.org
> Subject: Re: Hifn policy on documentation
>
> Marc Balmer wrote:
> > * Michael Scheliga wrote:
> >> truly open to the "general public" anonymous download site. I
doubt
> >> that the documentation that is being requested by developers is
putting
> >> you in violation of US Export Regulations. Your customer's
locations
> >
> > I live in Switzerland. Do I give a fuckin' rats ass for US Export
> > Regulations?
> >
>
>
> Not care about US Export Regs?
>
> But that just means you want the terrorists to win.
> After all our President is your President right?
>
> Sleep, Consume, Follow Orders. It's the American way.
Sorry, but when the company is in America, these are the
current laws. I don't see how hi-jacking the thread to
show that you don't like America or it's laws is going
to help with getting drivers for a Hifn card working better.
And I don't recall being asked what country I wanted to be
born into. Perhaps you were.
Trying to get something changed for the better, not trying to
push US laws down anybodies throat. If changing US law was as
simple as bitching about it in here, you wouldn't be able to
keep up with the volume of mail.
Michael
Andrew Dalgleish
[snip]
> And if you continue baiting me, I will delete the driver from our
> source tree.
You may as well. By the time Hifn release the documentation the speed
of cheap processors will have increased enough to make their current
products marginal.
I've had this happen with add-on DSP boards before.
Regards,
Andrew Dalgleish
NetNeanderthal
> Folks,
> There has been some discussion of late on this list about Hifn's policy
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
> The simple fact is that anyone who wants access to Hifn's documentation
> need only log on to our extranet site (http://extranet.hifn.com/home/)
The word simple implies no such thing in this instance. I went to the
site and it asked for me to register. What is that about?
> to download as much as they like. This is true of the 795x Algorithm
> accelerator chips and the 7855 and 8155 HIPP chips. Some more
> restrictions may apply to our NP and flow through part documents.
>
> Specifically the documentation for 7954, 7955 and 7956 is available.
> The other chips that are supported by the Open BSD Crypto drivers
> hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
> and 7854) are legacy parts that are not recommended for new designs.
> The driver will also work for 7954 even though that is not listed.
>
> This does represent some liberalization of access in recent months.
'some liberalization' means that you must compromise personal
information to gain access to docmentation used to sell your product?
Do you realize hifn's target industry?
> Hifn is always monitoring its policy with respect to the confidentiality
> of documentation and other business information. Some information will
> probably always require a non-disclosure agreement. Information that
> falls into that category is generally of a sensitive competitive nature,
> contains trade secrets or is related to unanounced or unreleased
> products.
Noone is asking for this information, why classify the other stuff
like it is ultra-secretive? The only thing gained (lost) is a
community that supports and sells your products for you.
> Software licenses are generally restricted in the disclosure or source
> code reproduction rights. Hifn reserves the right to keep our source
> code proprietary. This should not affect the hifn(4) driver since that
> driver is programmed directly to the hardware and does not use Hifn's
> enablement software library.
Well, as you stated, it doesn't affect the hifn(4) driver, so why
limit the disclosure of information?
> Registration at our extranet is required along with an email address
> that can be confirmed. We cannot support anonymous FTP or http
> downloads. The reason for this is that we are required by the
> conditions of our US export licenses to know who and where our customers
> are. If anyone objects to registration then we could not sell them
> chips anyway so it does not seem an unreasonable restriction to us.
What terms must be agreed upon when 'logging in' to this site or even
for registration?
It clearly asks when 'registering' for access 'Does your company
currently have an NDA/CDA with Hifn?'
No. Luckily, it's not required, or so it says.
After logging in, guess what is shown:
"Welcome new user. It normally requires several hours for our staff to
receive your new user registration and assign the appropriate
permissions to you. You will be unable to browse folders or access
files until we upgrade your access. You will be notified via email as
soon as your permissions have been set. Thank you for your patience.
Regards,
Brian Sparks
(408) 399-3520
bsp...@hifn.com "
Is this the link that you refer to for the documentation?
http://extranet.hifn.com/home/content/documents/?id=1736
If so, why not just make it publicly available? There was NO
information submitted that is verified other than eMail address, nor
any agreements signed that bind anyone to anything.
If anything, why not PROVIDE these 7956 Reference kits to developers?
Hifn owes THEM that much for all the hard work they do.
This is 'available documentation'? Are you seriously defending this
on a public mailing list?
Yes, free available documentation. What else lurks under these
proprietary PDF formats strewn about the site? And if they're
accessible by normal means, sans agreement, why can't they just be
posted without regard to registration or agreement? There is no
purpose for the compromise of personal information.
> I hope that this clears the air.
It doesn't. You're asking for the OpenBSD community, and especially
developers, to compromise the very values that have made OpenBSD what
it is today. I used to buy hifn products because they were
supported..and they 'just worked'. Now, I have no choice but to look
elsewhere. Don't think for a second that for ever person who posts a
complaint, there won't be a hundred thousand others who will read this
thread at some point and wonder if hifn is really the right choice for
their application.
Hank, did you really think that the legalese was in hifn's best
interests? Hifn's customers' interests? Congratulations, you've now
paid your attorneys to decrease support, and consequently, business.
Instead of removing the driver from the kernel, why not rename it to byefn(4)?
Breen Ouellette
> Marc Balmer wrote:
>> I live in Switzerland. Do I give a fuckin' rats ass for US Export
>> Regulations?
>>
>
>
> Not care about US Export Regs?
>
> But that just means you want the terrorists to win.
> After all our President is your President right?
I think nearly everyone here is fully aware of how American influence
affects the rest of the world. Using American laws as a scape goat to
try and pump personal information out of developers steps right into the
deep end of unreasonable legal wrangling. Hifn should realize that their
target market is interested in keeping information safe and private,
rather than exploiting developers for private information and using
inapplicable law as a sort of defacto shield against trouble with their
government. It only diminishes their reputation and perceived
trustworthiness in the eyes of customers, many of whom are making or
influencing the purchasing decisions for large foreign or multinational
organizations.
This is just another symptom of the US slide towards isolationism.
External competitive pressures are increasing every year and many
American institutions, both in government and private sector, are
seeking to restrict the trade of goods and ideas as a band aid to fix
the problem. The terrorist attacks of 2001 merely provided the powers
that be the excuse they needed to push isolationism further down the
throats of the American people.
Anyone who has been paying attention to China in the last ten years will
have a very good idea of where this type of policy is going to lead the
US economy. The sickest part is how China uses it's excess foreign
currency to buy American debt instruments, thereby encouraging low
interest rates in the US so that the American people can buy more
Chinese goods at Wal-Mart. We may soon see the last remaining super
power of the previous century decline into obscurity. Another decade
will tell us for sure.
Ahem. Sorry about that. Slightly off topic. :)
Breeno
Jacob Yocom-Piatt
>External competitive pressures are increasing every year and many
>American institutions, both in government and private sector, are
>seeking to restrict the trade of goods and ideas as a band aid to fix
>the problem.
i have wondered why companies like hifn want to keep their device design under
an NDA on many occasions. it seems to me to be mostly about a company's lack of
confidence in its competitive edge and their ability to maintain it. if you're
opening your drivers up, you had best be ready to "raise your skills", something
many amUricans are unwilling to do.
the whole idea of keeping the device docs under an NDA is silly to me. if anyone
REALLY wants those specs, e.g. your competitor, they can certainly get them
without too much additional trouble.
Eliah Kagan
> In this case, the vendor appears to be talking about documentation,
> which means they're actually confused. EAR covers chips but not
> documentation. By US law they *have* to care about the chips.
> Otherwise they're not in business. However the same law and a bunch of
> court cases also makes a big thing about "free speech". For quite a
> number of years, when cryptography was considered a munition and not
> allowed to be exported without special license, people were writing
> books and talking about cryptography almost entirely without problems.
> Somebody needs to point this out to them; there's simply no defensible
> US export legal reason for them to make people fill out web forms of
> any form to acquire human readable documentation.
As one example, Phil Zimmerman was not permitted to export the source
code to PGP electronically, so he published a print book containing it
in a character set particularly conducive to OCR (in the state of that
technology at that time). The issue there was that people in the NSA
and other anti-public-crypto goons in the US government were
comfortable and secure in their authority to obtain censorship of
electronic communications, but it was totally out of their league (at
least in that particular instance) to extend the censorious
regulations to the print medium.
So that issue is very real, but it is totally separate from what is
going on here, because:
(1) the materials in question are being distributed in an electronic form
(2) the materials in question are not actually subject to any US
export restrictions of any kind, and Mr. Cohen is either lying to us
or is quite misled.
The issue of the US government not being permitted to restrict speech
does not appear to me to be the applicable one here, because the only
organization that is acting against the interests of freedom in this
case is Hifn. They can blame the US government all they want--they're
lying (or severely and inexcusably mistaken).
-Eliah
Nick Guenther
> >There has been some discussion of late on this list about Hifn's policy
> >with respect to releasing documentation to the general public. That
> >discussion lead to a great deal of uninformed speculation and
> >unflattering statement's about Hifn's unfriendliness towards the open
> >source community. I would like to set the record straight.
> >
> I know that our hifn driver has some problems. But because I cannot
> get data sheets without giving you private information, I will not
> spend even one moment more of my time to improve support for your
> products. Jason and I spent a lot of time writing that code in the
> past, but because your policies are privacy invasive towards us, and
> thus completely thankless for the sales that we have given you in the
> past -- we will not spend any more time on your crummy products.
>
> source tree.
>
I don't use crypto accelerators, and none of this discussion applies
to me, so this is just noise... but I have to say this: this is
_AWESOME_. The project has not only scared the execs at this
corporation, now they are being torn to pieces by their previous
customers. I especially like Breen's response. A lot of other
communities would just be excited to be noticed, but not you guys. I
am not an OpenBSDer because I've been burned (not enough experience
for that) but because I recognized the philosophy as the only one that
is going to save humanity from itself.
Now, Hank Cohen, please come back and respond to some of these
replies. Stand up for your tribe. For the ones you missed, here's the
full thread (hosted somewhere that provides information for free,
perhaps you could learn from them):
http://marc.theaimsgroup.com/?l=openbsd-misc&m=115017551512719&w=2
-Nick
Barry, Christopher
> Sent: Tuesday, June 13, 2006 12:10 AM
> To: mi...@openbsd.org
> Subject: Hifn policy on documentation
>
> Folks,
> Hifn's policy
> with respect to releasing documentation to the general public. That
> discussion lead to a great deal of uninformed speculation and
> unflattering statement's about Hifn's unfriendliness towards the open
> source community. I would like to set the record straight.
>
> documentation
> need only log on to our extranet site (http://extranet.hifn.com/home/)
> accelerator chips and the 7855 and 8155 HIPP chips. Some more
> restrictions may apply to our NP and flow through part documents.
>
> Specifically the documentation for 7954, 7955 and 7956 is available.
> The other chips that are supported by the Open BSD Crypto drivers
> hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
> and 7854) are legacy parts that are not recommended for new designs.
> The driver will also work for 7954 even though that is not listed.
>
> This does represent some liberalization of access in recent months.
> confidentiality
> of documentation and other business information. Some
> information will
> probably always require a non-disclosure agreement. Information that
> falls into that category is generally of a sensitive
> competitive nature,
> contains trade secrets or is related to unanounced or unreleased
> products.
>
> code reproduction rights. Hifn reserves the right to keep our source
> code proprietary. This should not affect the hifn(4) driver
> since that
> driver is programmed directly to the hardware and does not use Hifn's
> enablement software library.
>
> that can be confirmed. We cannot support anonymous FTP or http
> downloads. The reason for this is that we are required by the
> conditions of our US export licenses to know who and where
> our customers
> are. If anyone objects to registration then we could not sell them
> chips anyway so it does not seem an unreasonable restriction to us.
>
>
> Hank Cohen
> Product Line Manager
> Hifn Inc.
> 750 University Ave
> Los Gatos Ca. 95032
> 408-399-3593
>
>
Actually, it's just ignorance on Hifn Marketing's part. It's really that
simple. Ignorance and stubborn misunderstanding, and it's incredibly
frustrating. It's not stupidity - there's a difference. Ya don't know
what ya don't know... They simply do not understand.
Hank, certainly you can see the relationship between driver support on
more platforms and increased product sales. It's just logical. More
chips sold, and you get a bigger bonus! You can also understand the need
for security and privacy - hence your product. Security is one of the
main reasons people gravitate toward OpenBSD. You really have a lot in
common. Check it out - OpenBSD people are writing code to support your
products, and not only is it not costing your company a penny, but it is
actively increasing the sale of your product. It's a total Win-Win. Do
the numbers.
When you look at the security minded bent of the OpenBSD community, what
I would say is a fierce loyalty to those vendors that 'get it', and the
fact that this thread will be available for all the World to see when
they Google 'hifn openbsd', and you should start seeing that by
stubbornly adhering to your policy, you are really just shooting
yourself in the foot.
What you *could* be doing is running as fast and hard as you can in the
*other* direction - by actively helping Open Source developers as much
as possible - and that means support with docs, dev kits, test hardware,
and maybe even a little financial support. That's the savvy, New World
MBA thing to do.
I see this all the time, most big vendors are clueless, and frankly my
company is guilty of it. What your company - and mine - need is to
employ the perspective and wisdom of those deeply into open source to
help them leverage the energy of those committed to providing quality,
free software. For hardware vendors, there is no better way. But doing
that correctly requires a real understanding of the culture, respect for
why these developers do what they do, and a cultivation of trust in the
community.
I hope that decrypts the air a bit more.
Regards,
-C
Travers Buda
"Hank Cohen" <hco...@hifn.com> wrote:
> Folks,
> There has been some discussion of late on this list about Hifn's
> policy with respect to releasing documentation to the general
> public. That discussion lead to a great deal of uninformed
> speculation and unflattering statement's about Hifn's unfriendliness
> towards the open source community. I would like to set the record
> straight.
etc...
Hank Cohen,
You really ought to consider what _you_ want, which, I guess
is a job at hifn. That's made possible by selling hardware. Despite how
reasonable your process seems to be, de Raadt threatened to remove
hifn from the tree. Though unlikely, Theo may be wrong. But that should
be none of your concern. This is not about who is right. Your concern is
making your customers happy.
Unhappy customers buy elsewhere.
Prospective customers who can't run your hardware buy elsewhere.
I'd personally like to be able to select the best hardware around and
be able to run it too. I like selection. Make the best chips and
see they're supported--then you will be able to fire the
advertising department.
Think of your money, Mr. Cohen. Think of mine.
Travers Buda
Bryan Irvine
> that can be confirmed. We cannot support anonymous FTP or http
> downloads. The reason for this is that we are required by the
> conditions of our US export licenses to know who and where our customers
> are. If anyone objects to registration then we could not sell them
> chips anyway so it does not seem an unreasonable restriction to us.
*cough*bullshit*cough*
I hope that this clears the air.
Hope in one hand....
--Bryan
Tony Abernethy
That gets a bit close to why I lurk on misc@ (and I doubt that I'm alone).
The people at OpenBSD understand hardware. They like to support hardware.
(I've run OpenBSD because the Linux driver of a SCSI card couldn't work
with the SCSI BIOS and I didn't want to boot from floppy). If something
is giving OpenBSD trouble, regardless of why, I do not expect the trouble
to stay confined to OpenBSD. If something, for whatever reason (including
"unreasonable" whims), is giving OpenBSD trouble, watch for it to give
trouble to Windows and Linux. ... somewhere, somehow ...
(It's like water has this tendency to more or less move downhill)
As to questionaires, as soon as something starts looking like
spam-harvesting I'm outa there.
(I am NOT "security-conscious", but I am also not THAT stupid.)
Siju George
> >with respect to releasing documentation to the general public. That
> >discussion lead to a great deal of uninformed speculation and
> >unflattering statement's about Hifn's unfriendliness towards the open
> >source community. I would like to set the record straight.
> >
> >need only log on to our extranet site (http://extranet.hifn.com/home/)
> >to download as much as they like.
>
> registration site that requires anyone who wants data sheets to enter
> approximately 50 personal questions.
>
Phew!
> I can get documentation for pretty much 99% of the chips in the
> industry without supplying any private information. I don't TRUST you
> to keep my personal data private.
>
Same case with many like me!
> >Specifically the documentation for 7954, 7955 and 7956 is available.
> >The other chips that are supported by the Open BSD Crypto drivers
> >hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
> >and 7854) are legacy parts that are not recommended for new designs.
> >The driver will also work for 7954 even though that is not listed.
>
> All of this is irrelevant. You require people to register. Do you
> understand what you are asking people to do? You are saying "Please
> give us all your private information, and then use the data sheets to
> write code that will help sell our product".
>
> >This does represent some liberalization of access in recent months.
>
> No it does not. 8 years ago all the above data sheets were fully available
> for download without any registration. Then about 5 years ago hifn closed
> up completely, and documentation was totally unavailable. About 2 years ago
> hifn went to this new model of "answer 50 personal questions".
>
> "50 personal questions" is not open access. Please don't lie about it.
>
> Other crypto chip vendors make their data much more easily available.
>
> >Hifn is always monitoring its policy with respect to the confidentiality
> >of documentation and other business information.
>
> No, hifn is not monitoring the effects of their policy at all. Over
> the last few years I have had extensive email conversations with hifn
> employees (including you) on this issue, and absolutely nothing has
> changed. You still think it is OK to get this personal information
> from people. You tried to pacify me in private mail.
>
And now after all that he wants to cheat the rest of us with this
innocent looking email.
And he even dares to send these lies to a public mailing list with no
regard to the consequences.
> >Some information will
> >probably always require a non-disclosure agreement. Information that
> >falls into that category is generally of a sensitive competitive nature,
> >contains trade secrets or is related to unanounced or unreleased
> >products.
>
> But we don't care about that information. We simply care about completely
> unfettered access to data sheets that were freely available without registration
> 8 years ago.
>
> >Software licenses are generally restricted in the disclosure or source
> >code reproduction rights. Hifn reserves the right to keep our source
> >code proprietary. This should not affect the hifn(4) driver since that
> >driver is programmed directly to the hardware and does not use Hifn's
> >enablement software library.
>
> The only person talking about hifn's proprietary code is you. If you showed
> it to us, we would not bother looking at it.
>
> >Registration at our extranet is required along with an email address
> >that can be confirmed. We cannot support anonymous FTP or http
> >downloads. The reason for this is that we are required by the
> >conditions of our US export licenses to know who and where our customers
> >are. If anyone objects to registration then we could not sell them
> >chips anyway so it does not seem an unreasonable restriction to us.
>
> So the personal information you ask for in the registration process
> will be given to the US government if they ask? Without court
> documents demanding the information?
>
> We are not your customers. YOU ARE OUR CUSTOMER. Our driver sells
> your chips.
>
> I know that our hifn driver has some problems. But because I cannot
> get data sheets without giving you private information, I will not
> spend even one moment more of my time to improve support for your
> products. Jason and I spent a lot of time writing that code in the
> past, but because your policies are privacy invasive towards us, and
> thus completely thankless for the sales that we have given you in the
> past -- we will not spend any more time on your crummy products.
>
> And if you continue baiting me, I will delete the driver from our
> source tree.
>
> I stand by my statement that HIFN is not open.
>
>
Mr Cohen,
I take recommendations for the hardware "I use and recommend to my clients" from
1) developers of OpenBSD,
2) manual pages
and
3) this mailing list to which you sent your mail.
As of now your hardware is not in my list of purchase nor do I
recommend it to any of my clients due to the lack of proper support
for it in OpenBSD.
And the reason for the lack of support is that your documentation is not free.
And I don't think anyone ( from what I hear at least in the OpenBSD
development team) is so desperate to write documentation for your
hardware after providing you with their personal information ( 50
questions! ARE YOU NUTS? ).
If you could do without this 8 years ago could you please tell us
what compels you to require this of people now? Also enlighten us what
you do or intend to do with this private data collected form us.
As of now I cannot buy your hardware not recommend it to my clients
because of your company's closed policy over Documentation.
Are you willing to change your stand? And make the Documentation
Freely accessible to the Developers?
If not I am not interested in reading your mails regarding this. And I
do not appreciate your lying about this matter.
--
Siju Oommen George, Network Consultant. HiFX IT & MEDIA SERVICES PVT.
LTD. http://www.hifx.net
Alexander Hall
non-abusive.
/Alexander
NetNeanderthal wrote:
> On 6/13/06, Hank Cohen <hco...@hifn.com> wrote:
>> Folks,
>> There has been some discussion of late on this list about Hifn's policy
>> with respect to releasing documentation to the general public. That
>> discussion lead to a great deal of uninformed speculation and
>> unflattering statement's about Hifn's unfriendliness towards the open
>> source community. I would like to set the record straight.
> I agree with others, the tone was correct at this point.
>
>> The simple fact is that anyone who wants access to Hifn's documentation
>> need only log on to our extranet site (http://extranet.hifn.com/home/)
> The word simple implies no such thing in this instance. I went to the
> site and it asked for me to register. What is that about?
>
>> to download as much as they like. This is true of the 795x Algorithm
>> accelerator chips and the 7855 and 8155 HIPP chips. Some more
>> restrictions may apply to our NP and flow through part documents.
>>
>> Specifically the documentation for 7954, 7955 and 7956 is available.
>> The other chips that are supported by the Open BSD Crypto drivers
>> hifn(4), lofn(4) and nofn(4) (7751, 7811,7951, 9751, 6500, 7814, 7851
>> and 7854) are legacy parts that are not recommended for new designs.
>> The driver will also work for 7954 even though that is not listed.
>>
>> This does represent some liberalization of access in recent months.
> 'some liberalization' means that you must compromise personal
> information to gain access to docmentation used to sell your product?
> Do you realize hifn's target industry?
>
>> Hifn is always monitoring its policy with respect to the confidentiality
>> of documentation and other business information. Some information will
>> probably always require a non-disclosure agreement. Information that
>> falls into that category is generally of a sensitive competitive nature,
>> contains trade secrets or is related to unanounced or unreleased
>> products.
> Noone is asking for this information, why classify the other stuff
> like it is ultra-secretive? The only thing gained (lost) is a
> community that supports and sells your products for you.
>
>> Software licenses are generally restricted in the disclosure or source
>> code reproduction rights. Hifn reserves the right to keep our source
>> code proprietary. This should not affect the hifn(4) driver since that
>> driver is programmed directly to the hardware and does not use Hifn's
>> enablement software library.
> Well, as you stated, it doesn't affect the hifn(4) driver, so why
> limit the disclosure of information?
>
>> Registration at our extranet is required along with an email address
>> that can be confirmed. We cannot support anonymous FTP or http
>> downloads. The reason for this is that we are required by the
>> conditions of our US export licenses to know who and where our customers
>> are. If anyone objects to registration then we could not sell them
>> chips anyway so it does not seem an unreasonable restriction to us.
>> I hope that this clears the air.
> It doesn't. You're asking for the OpenBSD community, and especially
> developers, to compromise the very values that have made OpenBSD what
> it is today. I used to buy hifn products because they were
> supported..and they 'just worked'. Now, I have no choice but to look
> elsewhere. Don't think for a second that for ever person who posts a
> complaint, there won't be a hundred thousand others who will read this
> thread at some point and wonder if hifn is really the right choice for
> their application.
>
> Hank, did you really think that the legalese was in hifn's best
> interests? Hifn's customers' interests? Congratulations, you've now
> paid your attorneys to decrease support, and consequently, business.
>
> Instead of removing the driver from the kernel, why not rename it to
> byefn(4)?
>
I top-post since I do not expect any answers to this post. Don't bother
complaining.
L. V. Lammert
> > Registration at our extranet is required along with an email address
> > that can be confirmed. We cannot support anonymous FTP or http
> > downloads. The reason for this is that we are required by the
> > conditions of our US export licenses to know who and where our customers
> > are. If anyone objects to registration then we could not sell them
> > chips anyway so it does not seem an unreasonable restriction to us.
>
> *cough*bullshit*cough*
>
BS aside, it's obvious you don't deal in US markets! While the
implementation may be flawed, dealing with export regulations, silly as
that may seem to non US organizations, CAN be business threatening. Not to
be taken lightly.
> I hope that this clears the air.
>
If anyone would like, we (as a US company) would be happy to use 'our'
registration information (providing the remaining license terms are
acceptable)! That probably isn't the issue, however, as the point about
actually obtaining hardware is also significant to US export markets.
Irrespective if the fact that more 'powerful' h/w can be obtained
with no restriction, getting 'current' h/w out of the states CAN be a
REAL hassle.
Lee
================================================
Leland V. Lammert l...@omnitec.net
Chief Scientist Omnitec Corporation
Network/Internet Consultants www.omnitec.net
================================================
L. V. Lammert
>L. V. Lammert wrote:
>>BS aside, it's obvious you don't deal in US markets! While the
>>implementation may be flawed, dealing with export regulations, silly as
>>that may seem to non US organizations, CAN be business threatening. Not to
>>be taken lightly.
>>
>>
>
>smoke screen or over-reaction on the part of Hifn. No one is asking Hifn
>to export hardware to Iran. No one is asking Hifn to export hardware at
>all. No one is asking for driver source code. As someone pointed out
>earlier in this thread, documentation may be sent out of the USA thanks to
>free speech laws.
Huh? What world are you living in? Export regulations for US companies are
EXTREMELY onerous, and if a company wants to do business internationally,
they have a ton of lawyers on staff playing games with things like this.
The fact that a company restricts documentation to US download to satisfy
export concerns is quite valid. If the TERMS of the license ON the
documentation are 'unrestricted use', that's where we need to direct our
attention.
>If entire algorithms can be printed in book form and exported, then
>certainly documentation on how to utilize a piece of hardware may leave
>the country without restriction. The documentation without the hardware is
>good for nothing. It's like having the operating documentation for a
>private jet - without the plane you aren't leaving the ground!
It's obvious you have never tried to export anything from the US with more
horsepower than a 386! ANY current technology on the 'watch list' cannot
LEAVE the country with about a weeks worth of work with the State
Deparement, Customs, et al.
If a companies' lawyers tell them to restrict documentation download to
valid organizations, that is well within their purvuew as technology
exporters. It's far more productive to be concerned with the terms OF the
license.
Lee
Theo de Raadt
> export concerns is quite valid. If the TERMS of the license ON the
> documentation are 'unrestricted use', that's where we need to direct our
> attention.
But that is not the point of the whole problem. The issue is that
Hifn says their documentation is open and freely available. It isn't.
And it is not just about the registration information, but quite
obviously the documentation is not available to everyone from every
country.
The problem is that they are saying it is open, but it is not. That
is a lie. And then one of their employees comes here, and tries to
set the record straight? And just ends up telling another series of
lies.
I don't care what their reasons are. Maybe they are valid (though we
strongly suspect they are false since some other crypto card companies
have no problems making documentation available).
But that's not the point.
Don't call it free if it isn't.
Breen Ouellette
> BS aside, it's obvious you don't deal in US markets! While the
> implementation may be flawed, dealing with export regulations, silly as
> that may seem to non US organizations, CAN be business threatening. Not to
> be taken lightly.
>
This issue has nothing to do with export regulations, this is either a
smoke screen or over-reaction on the part of Hifn. No one is asking Hifn
to export hardware to Iran. No one is asking Hifn to export hardware at
all. No one is asking for driver source code. As someone pointed out
earlier in this thread, documentation may be sent out of the USA thanks
to free speech laws. If entire algorithms can be printed in book form
and exported, then certainly documentation on how to utilize a piece of
hardware may leave the country without restriction. The documentation
without the hardware is good for nothing. It's like having the operating
documentation for a private jet - without the plane you aren't leaving
the ground!
> If anyone would like, we (as a US company) would be happy to use 'our'
> registration information (providing the remaining license terms are
> acceptable)! That probably isn't the issue, however, as the point about
> actually obtaining hardware is also significant to US export markets.
> Irrespective if the fact that more 'powerful' h/w can be obtained
> with no restriction, getting 'current' h/w out of the states CAN be a
> REAL hassle.
>
Something tells me that this is not going to fly. It only circumvents
the problem - it does not correct it. Using subversive means to bypass a
ridiculous system only supports and expands the ridiculousness of the
whole situation. I would guess that this is about as likely to happen as
Theo moving to the US to gain access to the docs.
Breeno
Adam
> Huh? What world are you living in? Export regulations for US companies are
> EXTREMELY onerous, and if a company wants to do business internationally,
> they have a ton of lawyers on staff playing games with things like this.
The real world. The one where making up complete nonsense doesn't make
it true.
> The fact that a company restricts documentation to US download to satisfy
> export concerns is quite valid.
No, it is not. There are no export concerns over documentation.
> It's obvious you have never tried to export anything from the US with more
> horsepower than a 386!
Documentation does not have more horse power than a 386. Its bad enough
that hifn employees make up bullshit like this, but why do random idiots
insist on defending their lies?
Adam
L. V. Lammert
>On Wed, 14 Jun 2006 09:54:02 -0500 "L. V. Lammert" <l...@omnitec.net> wrote:
>
> > Huh? What world are you living in? Export regulations for US companies are
> > EXTREMELY onerous, and if a company wants to do business internationally,
> > they have a ton of lawyers on staff playing games with things like this.
>
>The real world. The one where making up complete nonsense doesn't make
>it true.
Unfortunately, the 'Real World' seldom is aligned with the US Feds! Just
ask anyone that deals with Exports or the IRS. Sometimes it's truly amazing
that this country actually CAN get something done!
> > The fact that a company restricts documentation to US download to satisfy
> > export concerns is quite valid.
>
>No, it is not. There are no export concerns over documentation.
Huh? Better get yourself a lawyer before you land in jail! OTOH, you're not
in the US, so that explains the problem.
> > It's obvious you have never tried to export anything from the US with more
> > horsepower than a 386!
>
>Documentation does not have more horse power than a 386. Its bad enough
>that hifn employees make up bullshit like this, but why do random idiots
>insist on defending their lies?
We can all call the lawyers idiots (I'll be the first most of the time),
but, unfortunately, those of us in the business world must deal with them
AND various federal agencies. Ivory towers don't survive very long when
dealing with the Feds! Even those that TRY don't survive very long - just
look at Waco and Ruby Ridge.
Bottom line - nobody is going to change the US export regulations, we just
have to deal with them. If the license on vendor h/w & s/w **IS** to our
liking, there's no reason to dis them just because some lawyers MAKE them
verify that anyone downloading the docs is within the legal 'sphere' of
commerce. If registration is the ONLY complaint we have, that just COULD be
a symptom of their lawyers, so blame THEM and not everyone else.
Lee
Breen Ouellette
> It's obvious you have never tried to export anything from the US with
> cannot LEAVE the country with about a weeks worth of work with the
> State Deparement, Customs, et al.
>
If this is the case then my vpn1411 must have slipped through the
cracks, because it was exported to me a lot faster than you are implying.
And this still avoids the point - documentation detailing how to utilize
Hifn technology is useless without the hardware. I highly doubt that
Hifn documents provide details which would allow outsiders to replicate
their chips. If the export of the hardware is as tightly controlled as
you state then the safeguard is effective. Without the hardware any
driver created outside of the USA is useless. When someone shows me a
letter from US Customs stating that documentation allowing developers to
create interfaces for Hifn products may not be freely exported then I
will believe it. Until then it is nothing but smoke and mirrors, and no
matter what their excuse, it is going to end up hurting Hifn a lot more
than it hurts me or open source if Hifn doesn't find a way to fix it.
I'm out $60 + shipping and duties, and I stand to lose nothing more.
What does Hifn stand to lose?
Breeno
Adam
> Unfortunately, the 'Real World' seldom is aligned with the US Feds! Just
> ask anyone that deals with Exports or the IRS. Sometimes it's truly amazing
> that this country actually CAN get something done!
In what way is any of this relevant? Nobody is talking about exporting
anything, or income tax regulations.
> > > The fact that a company restricts documentation to US download to satisfy
> > > export concerns is quite valid.
> >
> >No, it is not. There are no export concerns over documentation.
>
> Huh? Better get yourself a lawyer before you land in jail! OTOH, you're not
> in the US, so that explains the problem.
Huh? Better get yourself a brain. If you want to insist that docs
are subject to any form of US law requiring data mining, then point
everyone to that law. Simply repeating nonsense over and over isn't
going to make it true.
> We can all call the lawyers idiots (I'll be the first most of the time),
> but, unfortunately, those of us in the business world must deal with them
> AND various federal agencies. Ivory towers don't survive very long when
> dealing with the Feds! Even those that TRY don't survive very long - just
> look at Waco and Ruby Ridge.
I'm not calling lawyers idiots. I am calling people who blindly rush
to defend the lies of random corporations idiots. In this case, that
would be you.
Adam
Spruell, Darren-Perot
> download to satisfy
> > > export concerns is quite valid.
> >
> >No, it is not. There are no export concerns over documentation.
>
> Huh? Better get yourself a lawyer before you land in jail!
> OTOH, you're not
> in the US, so that explains the problem.
Lee, take a step back and think about what you're trying to get at here.
Please support your statement that documentation falls under export
regulations. Documentation and specifications != hardware.
> > > It's obvious you have never tried to export anything from
> the US with more
> > > horsepower than a 386!
> >
> >Documentation does not have more horse power than a 386.
> Its bad enough
> >that hifn employees make up bullshit like this, but why do
> random idiots
> >insist on defending their lies?
I have to agree here. Stop being a drone and realize that this vendor is
being unreasonable.
DS
Allen Theobald
[snip]
> Please support your statement that documentation falls under export
> regulations. Documentation and specifications != hardware.
WARNING: NEWBIE ALERT, NEWBIE COMMENTS FOLLOW.
I have no dog in this fight but it only took me three minutes to
find "The Bureau of Industry and Security, U.S. Department of
Commerce:"
What Is an Export?
Any item that is sent from the United States to a foreign
destination is an export. "Items" include commodities,
software or technology, such as clothing, building materials,
circuit boards, automotive parts, blue prints, design plans,
retail software packages and technical information.
^
|
Interesting --------------------------+
How an item is transported outside of the United States does
not matter in determining export license requirements. For
example, an item can be sent by regular mail or hand-carried
on an airplane. A set of schematics can be sent via facsimile
to a foreign destination, software can be uploaded to or
downloaded from an Internet site, or technology can be
transmitted via e-mail or during a telephone conversation.
Regardless of the method used for the transfer, the transaction
is considered an export for export control purposes.
An item is also considered an export even if it is leaving the
United States temporarily, if it is leaving the United State
but is not for sale, (e.g. a gift) or if it is going to a
wholly-owned U.S. subsidiary in a foreign country.
Do data sheets qualify as "technical information" for purposes
of exporting? Beats the hell out of me. I'm sure there is
U.S. case law somewhere that spells it out.
We can't disagree on interpreting the facts if we can't agree
on the facts.
Kind Reagrds,
Allen
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Daniel Ouellet
[snip]
> source tree.
Here is my conclusion on this.
OpenBSD is the MOST secure OS on the planet and no one can dispute that.
PF is also the most secure firewall as well. No question there either.
So, why IT people use OpenBSD you think?
What are these same IT persons are doing for a leaving. Installing,
maintaining, recommending firewalls and hardware. Doing it at customers
sites. Talking to other IT person, making a leaving at it, etc!
Where do they communicate their informations, finding, complains,
success you think? Here!
Where do they look for the proper hardware to use. Here?
The bottom line, IT people use OpenBSD for what it excel at!
Where are "crypto accelerators" cards use you think?
Who will install them, buy them, use them, recommend them, support them?
Answer left for the reader....
What is asked is nothing compare to the benefit Hifn can get.
To finish, as far as I am concern, remove the driver for Hifn cards.
Why, well for the same reason I use OpenBSD. It's secure and stable! If
I can't get a "crypto accelerators card" that is secure, stable and
supported properly on my firewall, I don't want it and I sure don't want
to think twice about it. I don't want a possible security holes in my
firewalls, or customers firewall because something might not be
understood properly for the lack of documentations to support it. There
is other choices available. So be it.
See, I am lazy and like sales guys, I like to sleep at night! Not think
any firewall I am responsible for might be compromise because of a bad
drivers. Sorry, I value my time as well!
Hifn needs to understand it's market, users, supporters and obviously
they do not.
The same policy should apply here as it does for the OS at large.
Release when ready!
Adaptec was removed and we are better off and have more reliable
solutions now. So be it with Hifn crypto accelerators until they do.
Regards,
Daniel
Rod.. Whitworth
>I have to agree here. Stop being a drone and realize that this vendor is
>being unreasonable.
Exactly. Maybe getting to be desperate too?
http://tinyurl.com/n5xdo
From the land "down under": Australia.
Do we look <umop apisdn> from up over?
Do NOT CC me - I am subscribed to the list.
Replies to the sender address will fail except from the list-server.
Phil Howard
| usage. It's conceivable they think their competitors are actually
| stupid enough that this form will stop them from learning about what
| they're doing or coming up with better ways to do it. In any event,
| however justifiable they think they are in their business practices, it
| still stinks, and it bodes ill for their long-term business health.
| I wish their competition the best of luck.
Being as they are a publicly traded company (Nasdaq: HIFN) they have to
make certain SEC filings to fully disclose all the risks of the decisions
they make. This certainly needs to be among them. It might be worth a
look to see what they have filed in the past. Doing one thing and then
telling stockholders another is not a very tolerable practice.
Phil Howard
| If a companies' lawyers tell them to restrict documentation download to
| valid organizations, that is well within their purvuew as technology
| exporters. It's far more productive to be concerned with the terms OF the
| license.
So what if one of the driver writers for one of the open source operating
systems were to design a set of open standards for a hardware/software
interface for chipsets in this class. Then what if a chipset maker were
to actually use those open standards that are already published and in
the hands of developers and sophisticated users all over the world, so
that their chips can work in all the open source systems. Just how much
real difference exists between releasing the _interface_ specifications
(which could be derived easily from the open source drivers, anyway, no
matter what their origin) and using interface specifications that are
already widely public?
There's no difference in any of the issues the US law is trying to address.
It wants to be sure certain rogue nations and terrorists do not have the
ability to use strong encryption. If Theo were to sign his soul away to
get these specifications, anyone who manages to get the chips are going to
be able to use them by just running OpenBSD or copying the driver from it.
That's about as bad as it gets. It isn't any worse if the interface specs
are truly open. Terrorist wanting to use these chips, if they can get any,
would likely just use OpenBSD or some other OS the drivers are available
for. To stop the terrorists from being able to use them, stop them from
having the chips themselves (or the products the chips are in), and stop
the design of the chips from being released (not something Hifn would do
in any case).
This sillyness is like trying to prevent terrorist from having electricity
by not disclosing to them what the spacing between the prongs on electric
plugs is. It has absolutely nothing to do with it, and reeks of analysis
by a lawyer more interested in making it to the first tee by 3 PM.
Phil Howard
| Bottom line - nobody is going to change the US export regulations, we just
| have to deal with them. If the license on vendor h/w & s/w **IS** to our
| liking, there's no reason to dis them just because some lawyers MAKE them
| verify that anyone downloading the docs is within the legal 'sphere' of
| commerce. If registration is the ONLY complaint we have, that just COULD be
| a symptom of their lawyers, so blame THEM and not everyone else.
If Mr. Cohen had come here and said "Sorry, but our lawyer(s) insist that
we not make our interface documents open to people that don't play their
game of 50 questions" then I don't think people would be blaming him for
any of this. We'd just blame the lawyers. Instead, he tried to pass off
a closed documention process as being an open one, and that is just not
at all truthful. It's one thing for lawyers to be igorant about markets
and play extra safe harbor so they don't have to do the hard analysis to
figure out ways for the company to legally do this. It's quite another
for someone else to come and try to gloss over a bad decision with a lie.
If the company wants to make bad decisions, so be it. But what Mr. Cohen
did was at the very best a form of mis-representation about the decision.
Maybe Hifn's lawyer should be the one coming online, instead. Ultimately,
that does seem to be where the bad decisions originate, and it would help
eliminate a layer of communication that seems quite possibly to be one
that is passing bad information in both directions.
L. V. Lammert
> This sillyness is like trying to prevent terrorist from having electricity
> by not disclosing to them what the spacing between the prongs on electric
> plugs is. It has absolutely nothing to do with it, and reeks of analysis
> by a lawyer more interested in making it to the first tee by 3 PM.
>
Which is exactly the case I was making in the first place!
Darrin Chandler
>
> If Mr. Cohen had come here and said "Sorry, but our lawyer(s) insist that
> we not make our interface documents open to people that don't play their
> game of 50 questions" then I don't think people would be blaming him for
> any of this. We'd just blame the lawyers. Instead, he tried to pass off
I blame neither Mr. Cohen nor the lawyers. It's the decision makers at
the company who have decided this policy, which is a policy change from
years ago. Nobody else at the company is to blame. That's how
responsibility works.
I'm amazed and dismayed at how much time and effort people are putting
into this senseless discusssion of NOTHING.
--
Darrin Chandler | Phoenix BSD Users Group
dwcha...@stilyagin.com | http://bsd.phoenix.az.us/
http://www.stilyagin.com/ |
Wolfgang S. Rupprecht
> systems were to design a set of open standards for a hardware/software
> interface for chipsets in this class.
I guess the part I don't understand is why are open source folks so
wary of running black-box *.o binaries from a vendor but are quite
eager to use blackbox crypto cards (that effectively run blackbox *.o
firmware)?
While I don't think these cards really do contain trojans, they
certainly could at some point in the future. What prevents the
manufacturers from storing all keys into some on-chip nv-ram for later
retrieval? Ditto for the card intentionally leaking the keying data
into the cipher stream? At one point during the cold-war it certainly
seemed like the US did manage to slip a leaky key trojan into a well
respected company's cipher system.
http://mediafilter.org/caq/cryptogate/
-wolfgang
Eliah Kagan
> I blame neither Mr. Cohen nor the lawyers. It's the decision makers at
> the company who have decided this policy, which is a policy change from
> years ago. Nobody else at the company is to blame. That's how
> responsibility works.
No, it's not.
If you do something that is morally reprehensible, it is morally
reprehensible whether or not you are doing it because you were ordered
to do it. For Mr. Cohen to tell us lies or inexcusably misinformed
statements reflects negatively on him personally, because that is
something that no one ought to do.
Perhaps Mr. Cohen would be fired if he refused to act immorally. That
doesn't mean that his actions are beyond criticism.
I don't think that anybody, prior to the post I am making right now,
has called Mr. Cohen or the lawyers into question for their individual
morality. Up to this point, we have been criticizing what Mr. Cohen
said, and we have been criticizing Hifn the company and any and all
employees who would carry out actions on behalf of the company with
which we disagree and with which we believe to constitute bad business
and degradation of users' freedom. This has included but has at no
point been limited to or particularly focused on Mr. Cohen. But now
that you bring it up, yes, Mr. Cohen made the wrong decision when he
chose to carry out the will of his company. And since he is the
"Product Line Manager" (read his signature), he was probably involved
in establishing just what the will of his company is.
-Eliah
ve...@skreel.org
I have to admit that I find it quite amusing how some people that do
restrict access to documentation are the same that do take advantage
of other people's free documentation ...
http://marc.theaimsgroup.com/?l=openssl-users&m=114832209207203&w=2
Oh ... wait ... no. I don't find that amusing, and Hifn is no longer
in the vendors list I maintain for the company I work at.
A while ago, someone mentionned the opening of a wiki to help find a
list of specs friendly and unfriendly vendors, how is it going ?
Jeff Quast
http://www.vendorwatch.org/ , hifn is marked as unfriendly. I really
like this site, too. Congrats to the contributors.
knitti
<wolfgang+...@dailyplanet.dontspam.wsrcc.com> wrote:
> Ditto for the card intentionally leaking the keying data
> into the cipher stream?
to add FUD to it. any algorithm the cards claim to implement _is_ fully
documented, so you can test any output except that of the RNG against a
'known good' implementation
--knitti
Darrin Chandler
> On 6/14/06, Darrin Chandler <dwcha...@stilyagin.com> wrote:
> >I blame neither Mr. Cohen nor the lawyers. It's the decision makers at
> >the company who have decided this policy, which is a policy change from
> >years ago. Nobody else at the company is to blame. That's how
> >responsibility works.
>
> No, it's not.
>
> If you do something that is morally reprehensible, it is morally
> reprehensible whether or not you are doing it because you were ordered
> to do it. For Mr. Cohen to tell us lies or inexcusably misinformed
> statements reflects negatively on him personally, because that is
> something that no one ought to do.
So? If it weren't Mr. Cohen, if would be someone else from Hifn. From
*my* point of view as a user of OpenBSD their reasons and moral standing
don't matter because they won't open the specs on their hardware. If
they did open the specs, then there might be other reasons for me not to
do business with them. As it stands there's already one show stopper.
That's enough.
Look, it's pretty obvious from early exchanges in this thread that these
issues have been discussed by the principal parties over a fairly long
period of time. How many brilliant insights have been added by this
thread? More important, has this thread opened up Hifn's specs? Has this
discussion accomplished anything at all?
Breen Ouellette
> Look, it's pretty obvious from early exchanges in this thread that these
> issues have been discussed by the principal parties over a fairly long
> period of time. How many brilliant insights have been added by this
> thread? More important, has this thread opened up Hifn's specs? Has this
> discussion accomplished anything at all?
>
>
crank the heat up a couple of notches. If the principle parties come in
and ask us to stop it will go a lot futher than you, some random person,
asking us to stop. I don't see Theo complaining, and he has a far
greater vested interest than you. I haven't seen other developers
complaining, and the same goes for them. I haven't even seen Hifn
complaining, although that would only weaken their position further.
2) It's not about brilliant insights. It is about customer
dissatisfaction. People are posting so there is a record that they are
not happy with the situation, and this record covers very clearly why
they are not happy with the situation. This goes a long way towards
punishing Hifn for what we perceive as acts which are not in our best
interests as customers. The alternative is silence, which allows Hifn to
continue to dupe customers. I do not want to see another person duped
like this, and it is now my personal mission to do what I am able to
prevent it from happening again.
3) Has this thread opened up Hifn's specs??! You expect results to take
place in an unreasonable amount of time. Change doesn't always happen
overnight, especially when corporations are involved.
4) This discussion has definitely accomplished something - it has
created a freely accessible, mirrored record which points out some very
serious flaws in the policies of a supposed security minded company. As
a consumer I have relied on exactly this sort of thing time and time
again to avoid bad purchases. I wish this thread had existed three
months ago so I wouldn't have purchased a blasted Hifn product that sits
unused on my shelf!
And above all this, this thread shows that, for the most part, users are
behind the policies of the OpenBSD project. This sends a clear message
to the industry that we will hurt their bottom line if they screw around
with us. I only wish more projects and organizations would toe this line.
Breeno
Breen Ouellette
> I guess the part I don't understand is why are open source folks so
> wary of running black-box *.o binaries from a vendor but are quite
> eager to use blackbox crypto cards (that effectively run blackbox *.o
> firmware)?
>
>
the hardware, so why don't we just give them the keys to the kingdom and
allow them to do it in software?
HUH???
Given your argument we may as well just let them have root access to our
machines. Or maybe they could install cameras in our offices and homes
while they are at it.
Breeno
Breen Ouellette
> oh come on, this discussion is already as off topic as it can be, no need
> to add FUD to it. any algorithm the cards claim to implement _is_ fully
> documented, so you can test any output except that of the RNG against a
> 'known good' implementation
This is a great point. However...
This is not off topic. This topic definitely affects OpenBSD and serves
a purpose. I do not understand why people think this is off topic. Since
when was misc@ only for posting about technical problems?
Talking about the World Cup matches would be off-topic. Talking about
Billy Graham's last sermon would be off topic. Hifn's crappy policy and
why we don't like it is definitely on topic.
Breeno
Darrin Chandler
> 1) The principle parties' exchanges didn't go anywhere. It is time to
> crank the heat up a couple of notches. If the principle parties come in
> and ask us to stop it will go a lot futher than you, some random person,
> asking us to stop. I don't see Theo complaining, and he has a far
> greater vested interest than you. I haven't seen other developers
> complaining, and the same goes for them. I haven't even seen Hifn
> complaining, although that would only weaken their position further.
I don't expect everyone to stop because I said so. I'm hoping that at
least a few of you will go do something productive instead.
> 2) It's not about brilliant insights. It is about customer
> dissatisfaction. People are posting so there is a record that they are
> not happy with the situation, and this record covers very clearly why
> they are not happy with the situation. This goes a long way towards
> punishing Hifn for what we perceive as acts which are not in our best
> interests as customers. The alternative is silence, which allows Hifn to
> continue to dupe customers. I do not want to see another person duped
> like this, and it is now my personal mission to do what I am able to
> prevent it from happening again.
>
> 3) Has this thread opened up Hifn's specs??! You expect results to take
> place in an unreasonable amount of time. Change doesn't always happen
> overnight, especially when corporations are involved.
>
> 4) This discussion has definitely accomplished something - it has
> created a freely accessible, mirrored record which points out some very
> serious flaws in the policies of a supposed security minded company. As
> a consumer I have relied on exactly this sort of thing time and time
> again to avoid bad purchases. I wish this thread had existed three
> months ago so I wouldn't have purchased a blasted Hifn product that sits
> unused on my shelf!
>
> And above all this, this thread shows that, for the most part, users are
> behind the policies of the OpenBSD project. This sends a clear message
> to the industry that we will hurt their bottom line if they screw around
> with us. I only wish more projects and organizations would toe this line.
This discussion made it to the front page of Slashdot, giving Hifn a lot
of free publicity. It gives them the opportunity to tell everyone again
that you can just go get their specs online. Maybe they can offer a nice
BLOB to the Linux distros and get it accepted like nVidia. Maybe due to
this they will sell MORE hardware than before.
If half the people heavily involved with this thread had drawn up a well
worded message and sent it to Hifn it would have had a better effect, I
bet.
We'll see. I surely don't expect policy changes overnight. If Hifn truly
opens their specs in the next year I'll be surprised. And that is what
will change my mind about the value of this discussion.
FYI, someone recently mentioned www.vendorwatch.org. It's a nice
resource, and I hope it grows. I keep forgetting it's there. Next time
I'm shopping for hardware I'll be checking there!
Tony Abernethy
>
> Darrin Chandler wrote:
> > Look, it's pretty obvious from early exchanges in this thread that these
> > issues have been discussed by the principal parties over a fairly long
> > period of time. How many brilliant insights have been added by this
> > thread? More important, has this thread opened up Hifn's specs? Has this
> > discussion accomplished anything at all?
> >
> >
> crank the heat up a couple of notches. If the principle parties come in
> and ask us to stop it will go a lot futher than you, some random person,
> asking us to stop. I don't see Theo complaining, and he has a far
> greater vested interest than you. I haven't seen other developers
> complaining, and the same goes for them. I haven't even seen Hifn
> complaining, although that would only weaken their position further.
>
> dissatisfaction. People are posting so there is a record that they are
> not happy with the situation, and this record covers very clearly why
> they are not happy with the situation. This goes a long way towards
> punishing Hifn for what we perceive as acts which are not in our best
> interests as customers. The alternative is silence, which allows Hifn to
> continue to dupe customers. I do not want to see another person duped
> like this, and it is now my personal mission to do what I am able to
> prevent it from happening again.
>
> 3) Has this thread opened up Hifn's specs??! You expect results to take
> place in an unreasonable amount of time. Change doesn't always happen
> overnight, especially when corporations are involved.
>
> 4) This discussion has definitely accomplished something - it has
> created a freely accessible, mirrored record which points out some very
> serious flaws in the policies of a supposed security minded company. As
> a consumer I have relied on exactly this sort of thing time and time
> again to avoid bad purchases. I wish this thread had existed three
> months ago so I wouldn't have purchased a blasted Hifn product that sits
> unused on my shelf!
You can then appreciate why I lurk on this list, and how I can easily talk
my tightwad CEO in buying a couple of CDs that I "might" need to use.
For a lot of this stuff, the OpenBSD users and developers will take good
care of themselves. But a lot of this does matter to us (bluntly) outsiders.
If security actually matters (not some snake-oil fiction) the first rule
has to be something like not fooling yourself. Something like this thread
is probably the only plausible mechanism to establish what the ground
rules SHOULD be for such as this. Maybe not a good chance, but seems to me
like maybe it is the only chance.
>
> And above all this, this thread shows that, for the most part, users are
> behind the policies of the OpenBSD project. This sends a clear message
> to the industry that we will hurt their bottom line if they screw around
> with us. I only wish more projects and organizations would toe this line.
>
> Breeno
Phil Howard
| > So what if one of the driver writers for one of the open source operating
| > systems were to design a set of open standards for a hardware/software
| > interface for chipsets in this class.
|
| I guess the part I don't understand is why are open source folks so
| wary of running black-box *.o binaries from a vendor but are quite
| eager to use blackbox crypto cards (that effectively run blackbox *.o
| firmware)?
Don't assume that everyone is even willing to hand over their private
data to some "sealed black box". There are, of course, a number of
differences. What runs on the card/chip generally won't have access
to the rest of the system (assuming reasonable bus security, which may
not be true). But a *.o binary driver will have that access to the
level it is installed (probably the kernel, which means it has access
to everything). Bugs in the *.o could crash or hang the kernel if it
is there. But in the card/chip it is less likely to cause damage,
although that isn't impossible (could lock up the bus). I'd be a bit
more trusting of a crypto device that was connected via some soft means
like an ethernet. But that still implies a (possibly misplaced) trust
in the ethernet card itself.
Then there is the issue of whether they provide kernel level *.o files
for all the platforms OpenBSD and other systems support.
| While I don't think these cards really do contain trojans, they
| certainly could at some point in the future. What prevents the
| manufacturers from storing all keys into some on-chip nv-ram for later
| retrieval? Ditto for the card intentionally leaking the keying data
| into the cipher stream? At one point during the cold-war it certainly
| seemed like the US did manage to slip a leaky key trojan into a well
| respected company's cipher system.
Similar risk could exist in CPU based crypto instructions, too, if such
a CPU were to be made public.
Ultimately, I'll personally depend on crypto in software I can access for
myself. I think that's your real point.
FYI, I don't even trust Theo for writing safe crypto software. But that's
not a personal statement ... it's just a statement of procedure; I would
not trust anyone, period. The big advantage of open source that we all
already know is the "many eyes (with no conflict of interest)" aspect.
That cannot be said for either binary software or hardware implementations.
What interests me among Hifn's chips are not the crypto capabilities, but
the compression capabilities. No export regulations for that as long as
it doesn't have the crypto in it, so those should be fully open (I have
not checked) as to interface and interoperability (e.g. uses a standard
compression format). Even data compression in a sealed box has risks,
such as it detecting actual keys being moved around in the clear and saving
them into NVRAM. How do you know your CPU doesn't have this?
Wolfgang S. Rupprecht
> Ultimately, I'll personally depend on crypto in software I can access for
> myself. I think that's your real point.
Thanks for the well thought-out reply.
I too would place a heck of a lot less trust in some crypto chip than
something that is inspectable.
> What interests me among Hifn's chips are not the crypto capabilities, but
> the compression capabilities.
Interesting. I didn't realize they did that. It looks like a safe
enough use.
knitti <kni...@gmail.com> writes:
> any algorithm the cards claim to implement _is_ fully documented, so
> you can test any output except that of the RNG against a 'known
> good' implementation
Even if the cipherstream out of a chip is the same as the software
implementation in general, what prevents the chip from switching to a
trojan mode when it sees a certain data-pattern in the plaintext input
stream? Sure the other side might not be able to decrypt the doctored
up cipherstream, but the information would have already been leaked.
Heck, if both sides use the same chip, the receiving chip could even
recognize the data stream and pretend that nothing out of the ordinary
were going on.
Personally I don't see how a hardware chip maker can prove that the
chip doesn't have a trojan without providing masks for inspection and
a way to prove that those masks and only those masks were used to make
the chip. Open source and all that.
-wolfgang
--
Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/
Siju George
I 've been told by people ( more than one ) off list how *uncivilized*
it is to forward *private* mail publicly *even when it has some bad
content*.
And I have been asked to apologize publicly ( not by Hank Cohen ).
Without trying to Justify my points any more I apologize doing this.
I am wrong. I accept it.
Sorry Hank. I know the damage is done. But I 'll make sure that it is
not repeated anymore.
And thank you so much for all who sent the mails of reproof and correction.
Thank you for taking effort to put me in the right track.
And thank you so much for all who silently put up with this misbehaviour.
Kind Regards
Siju
On 6/14/06, Siju George <sgeor...@gmail.com> wrote:
> Hi all,
>
> This is the mail I got from Hifn representative for my response to his
> mail and clarifications in misc.
>
> This mail was sent to me privately and I am well aware of the fact
> that it is not good manners to make private mails public. In that way
> i am just going down a little bit down on that. let people see the
> response they get from Hifn.
>
> And Mr. Cohen, If what you sent to the list was indeed not a lie then
> I sincerly apologize mentioning that you were lying in my previously
> mail. I apologize publicly just as I mentioned it publicly.
>
> Also I would like to let you know very humbly that this may not be a
> very good way of treating your potential customers.
>
> Thanks for you complements any way :-)
>
> Good Luck ahead with this policy of your company and you personal behaviour.
>
> Kind regards
>
> --Siju
>
>
>
>
> ---------- Forwarded message ----------
> From: Hank Cohen <hco...@hifn.com>
> Date: Jun 14, 2006 10:43 AM
> Subject: RE: Hifn policy on documentation
> To: Siju George <sgeor...@gmail.com>
>
>
> Mr. george.
> I do not appreciate being accused of lying.
> If you choose not to use Hifn products then so be it.
> I have announced our policy in good faith and been treated to
> a barrage of insult and invective. If I were speaking on my own
> account I would feel free to tell you what I really think of this kind
> of bullshit but I cannot do so since I will always be seen as a
> representative of my company.
>
> You sir have the manners of a pig. And I shall surely never
> recommend your IT and Media services to anyone either.
> Having said that perhaps you can understand how much your
> threats are likely to have the result that you desire.
>
> Hank Cohen
> On my own account.
>
--
Siju Oommen George, Network Consultant. HiFX IT & MEDIA SERVICES PVT.
LTD. http://www.hifx.net
Breen Ouellette
> I 've been told by people ( more than one ) off list how *uncivilized*
> it is to forward *private* mail publicly *even when it has some bad
> content*.
I wouldn't sweat it too much. It would be one thing to bait him by first
promising not to go public with his mail and _later_ taking it public,
but it seems unreasonable to expect that an aggressive, unsolicited
email will be kept private by the receiver. If someone sends me a
crazy-angry email like you received, the first thing I do is get it on
the public record. If you don't want to be judged on something you have
written unsolicited in anger, then do not send angry, unsolicited email!
Just yesterday Poul-Henning Kamp reposted to soekris-tech select parts
of private email replies which I made to him regarding the Hifn debate.
He chose to repost only those parts of my messages for which he had
snappy answers, failed to disclose the remainder of my messages, and
then ended the discussion by implying that I was a communist. In the
same sentence he also implied that my world view is uncompromising,
while it was obvious that in his own world view he is ultimately right
and a difference of values is not possible - disagreeing with him makes
you wrong by default. "Discussion over."
The weirdest part is that he was backing up someone who wanted me to
take my "rhetoric" off list, so I responded to him in private and then
he selectively replied back to the list. Go figure.
It wasn't even worth mentioning until you brought up this somewhat
similar situation. Ultimately, people will weigh the facts and decide
what they want. Many people will feel that you did nothing wrong, just
like many people will read Mr. Kamp's public responses to my private
messages and realize that he is not presenting the whole picture. I'm
sorry that some people convinced you to back down on your position, but
for what it's worth I thought you did the right thing by posting the
Cohen reply. I actually felt that your original message was too strongly
worded and that Cohen had good reason to be angry, but, "on [Cohen's]
own account" or otherwise, it was damned unprofessional of him to
respond in private as he did. He should have posted a professional
message to the list requesting a retraction of the accusation that he
was lying, barring contrary evidence of his honesty. It actually ended
up reinforcing my perception that they lack a pulse (or maybe a soul)
over at Hifn. If this is how a PR rep for the company reacts to
unflattering statements, what about the average Joe in their employ?
It's no wonder Theo has problems with them.
Breeno
Eliah Kagan
> Hi all,
>
> I 've been told by people ( more than one ) off list how *uncivilized*
> it is to forward *private* mail publicly *even when it has some bad
> content*.
>
>
> Without trying to Justify my points any more I apologize doing this.
> I am wrong. I accept it.
>
> Sorry Hank. I know the damage is done. But I 'll make sure that it is
> not repeated anymore.
>
> And thank you so much for all who sent the mails of reproof and correction.
> Thank you for taking effort to put me in the right track.
> And thank you so much for all who silently put up with this misbehaviour.
You did nothing wrong.
Email is fundamentally not private unless and until (1) all the
correspondents have reason to trust one another, and (2) they mutually
agree to keep the correspondence private, and (3) the emails are
encrypted, or the emails are only private in a very trivial sense. (1)
is unlikely given that Mr. Cohen's email was in response to you
accusing him of lying. (2) is impossible since the email was
unsolicited. And I am guessing (3) was not the case.
While there is a wider variety circumstances than 1+2+3 in which it is
considered impolite to redistribute private emails, beyond that, it's
your call, and nobody should assume that you will keep their words
privileged (and I seriously doubt Mr. Cohen expected it). Furthermore,
only someone who fundamentally misunderstands the concepts of
reasonable assumption of privacy and conversational intimacy would
think that your posting of Mr. Cohen's unsolicited message qualifies
for this category of "extended impoliteness". And there are many such
people--just look at how many companies require universal use of
signatures stating things like "the contents of this message are
private" and "if you are not the intended recipient, you are required
to delete this message immediately and you may not use its contents".
At the risk of starting something that really would be off-topic, I
would like to point out that when people attribute privacy and
privilege where they do not exist, the notions of privacy and
privilege are degraded, and the ability of all people to enjoy those
things where they do exist is diminished.
We should focus less on being "civilized" and more on fulfilling our
obligations to one another, where those obligations exist. It is
largely due to the actions and inactions of "civilized" people that
many of those obligations are not fulfilled, every day, all over the
world. Please understand that I am not trying to knock etiquette,
which I think is very important because it provides a protocol with
which people can communicate. But as I have just argued, I don't think
that etiquette is a big issue in this case. I think calling an
unsolicited email from a company representative responding to a post
to a public mailing list addressing a former post to the same mailing
list by the company representative about a company matter "private" is
dangerous to our continued enjoyment of privacy. I further think that
encouraging people to keep private fundamentally non-private
correspondence has the effect of giving license to people to send
abusive and non-productive emails.
-Eliah
Siju George
Just after I send this I saw Hank's mail in my inbox with sincere
apology for his mail sent to me in private. And I 've put that part of
the matter behind me now. He has also stated that he does not hold any
grudge againt me or anyone. I thought it is fit to state it here. Not
posting the full mail since it is also send in private.
Thanks to all for you patience, suggestions and care. There are too
many to mention with names now.
Kind Regards
Siju
On 6/17/06, Siju George <sgeor...@gmail.com> wrote:
> Hi all,
>
> I 've been told by people ( more than one ) off list how *uncivilized*
> it is to forward *private* mail publicly *even when it has some bad
> content*.
>
> And I have been asked to apologize publicly ( not by Hank Cohen ).
>
> Without trying to Justify my points any more I apologize doing this.
> I am wrong. I accept it.
>
> Sorry Hank. I know the damage is done. But I 'll make sure that it is
> not repeated anymore.
>
> And thank you so much for all who sent the mails of reproof and correction.
> Thank you for taking effort to put me in the right track.
> And thank you so much for all who silently put up with this misbehaviour.
>