I'm not sure how encryption can solve a problem of "truth or falsity".
Public key encryption only says that the message that is decrypted using
the public key must have been encrypted by someone who knows the private
key.  A person can use their private key to encrypt a lie as well as the
truth.

   I don't quite follow your prescription, but if you are saying that
the beamline gives the depositor a code when they collect data that
proves data were collected, how does the beamline personal know the
contents of the crystal?  Couldn't one simply collect HEWL and then
deposit any model they like?

   The beamline could encrypt all images with their private key, and
the data integration program could decrypt the images using the public
key.  That way when a depositor presents a set of images it could be
proved that those images came, unmodified, from that beamline.  The
images would still have to be deposited, however.  (And this provides
no protection against forgeries of home source data sets.)

Dale Tronrud

On 04/03/12 13:19, Bryan Lepore wrote:
> On the topic of MX fraud : could not an encryption algorithm be
> applied to answer the question of truth or falsity of a pdb/wwpdb/pdbe
> entry? has anyone proposed such an idea before?
> 
> for example (admittedly this is a mess):
> 
> * a detector parameter - perhaps the serial number - is used as a
> public key. the detector parameter is shared among
> beamlines/companies/*pdb. specifically, the experimentor requests it
> at beamtime.
> 
> * experimentor voluntarily encrypts something, using GPLv3 programs,
> small but essential to the deposition materials, like the R-free set
> indices (or please suggest something better), using their private key.
> maybe symmetric cipher would work better for this. or the Free R set
> indices are used to generate a key.
> 
> * at deposition time, the *pdb unencrypts the relevant entry
> components using their private key related to the detector used.
> existing deposition methods pass or fail based on this (so maybe not
> the Free R set).
> 
> * why do this : at deposition time, *pdb will have a yes-or-no result
> from a single string of characters. can be a stop-gap measure until
> images can be archived easily. all elements of the chain are required
> to be free and unencumbered by proprietary interests. importantly, it
> is voluntary. this will prevent entries such as Schwarzenbacher or
> Ajees getting past deposition - so admittedly, not many.
> 
> references:
> http://en.wikipedia.org/wiki/RSA_(algorithm)
> http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange
> 
> -Bryan

Reply via email to