Stata The Stata listserver
[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Encrypting and decrypting a field


From   Alan Neustadtl <alan.neustadtl@gmail.com>
To   statalist@hsphsun2.harvard.edu
Subject   Re: st: Encrypting and decrypting a field
Date   Fri, 1 Apr 2005 08:49:33 -0500

While there may be restrictions on the suppliers of data from their
end, at American universities there are clearly issues about use of
data.  Every research project must be reviewed by an Institutional
Review Board that has a mandate to protect the rights of study
participants.  IRB's are run differently across universities and
researchers experiences vary accordingly.

I guess there is some safety having protections at both ends.

Best,
Alan

On Apr 1, 2005 5:21 AM, Nick Cox <n.j.cox@durham.ac.uk> wrote:
> Here is what may be a very naive answer.
> 
> I wouldn't want people to give me data that
> were sensitive if they didn't trust me, or
> the security of the systems I work on. And
> I certainly can't vouch that the latter are
> hacker-proof.
> 
> Why isn't the onus on the data supplier to
> do the encrypting themselves?
> 
> Nick
> n.j.cox@durham.ac.uk
> 
> Joseph Coveney
> 
> > bobf@pacbell.net wrote:
> >
> > I will be receiving data files that include as the primary ID a social
> > security number (SSN). Yes, using SSNs as IDs is a worrisome
> > practice, but
> > the agency we are dealing with is not going to change this
> > policy, at least
> > in the near term.
> >
> > I am obligated to protect the privacy of this information,
> > and if the data
> > production were a one-time event, I could use some variant of
> > a uniformly
> > distributed random number to generate an alternative ID and keep the
> > cross-walk between the SSN and the uniform random number locked in a
> > separate location. However, there will be ongoing updates
> > that will require
> > match merges based on the SSN, along with the addition of new
> > cases to the
> > population.
> >
> > Has anyone on the list developed code for
> > encrypting/decrypting a field
> > that they could send me? I know that there is C++ code in the
> > free Cryptlib
> > toolkit but I would prefer not to have to plunge into this unless it's
> > really necessary.
> >
> > --------------------------------------------------------------
> > --------------
> >
> > Did you ever receive a response to this?
> >
> > I can't answer about encrypting variables, but I would be
> > interested in
> > knowing how others in the Stata user community are
> > approaching this, how
> > they are adapting the ways in which they use Stata to meet
> > the demands of
> > their institutions' data-protection or privacy-protection policies.
> >
> > For example, if it is used as a client application with a
> > database residing
> > on a server elsewhere on campus, I assume that there wouldn't be any
> > unexpected glitch using Stata with the various protocols for
> > tunneling ODBC
> > traffic.  And I assume that policy would require users to be
> > trained in
> > proper procedure, but are institutions requiring Stata be
> > "qualified" in
> > some respect before allowing its use on privacy-protected data?
> 
> *
> *   For searches and help try:
> *   http://www.stata.com/support/faqs/res/findit.html
> *   http://www.stata.com/support/statalist/faq
> *   http://www.ats.ucla.edu/stat/stata/
>
*
*   For searches and help try:
*   http://www.stata.com/support/faqs/res/findit.html
*   http://www.stata.com/support/statalist/faq
*   http://www.ats.ucla.edu/stat/stata/



© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index