I am interested in publishing a program that would in turn call upon POV Ray
to render an output image.
The image, actually a series of images, would be something like a building
'walk-through'.
Is there ant way in which the source .POV file could be encrypted so that
the user would not have access to this source.
This problem comes from my potential use of materials that are covered by a
copywrite, where the copywrite owner dictates that I may freely use and
publish the material in a final image format but may not divulge the source
data.... tricky !

Post a reply to this message

David Vincent-Jones <geo### [at] galaxynetcom> wrote:
: Is there ant way in which the source .POV file could be encrypted so that
: the user would not have access to this source.

  Nope.
  Povray itself have to get, some way or another, a valid pov source code to
read. So if povray can get it, then the user can get it as well.

  Of course one way of "dumb-encrypting" the file would be to code it in
some way into a string or into an array of numbers and then making a loop
that writes parts of the encoded code into a file and then includes that
file (this could be made in parts so that only a part of the file is in
non-encrypted form at a time).
  This, of course, would stop only the most newbies from getting your code.
It would not require much knowledge about the pov-script to modify the loop
a bit so that it writes everything to a file and that's it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

if you are writing the program that will send it to povray, you could
make your own encription file that is decoded to a temporary pov file at
runtime and then erased when the image is done....?

Warp wrote:
> 
> David Vincent-Jones <geo### [at] galaxynetcom> wrote:
> : Is there ant way in which the source .POV file could be encrypted so that
> : the user would not have access to this source.
> 
>   Nope.
>   Povray itself have to get, some way or another, a valid pov source code to
> read. So if povray can get it, then the user can get it as well.
> 
>   Of course one way of "dumb-encrypting" the file would be to code it in
> some way into a string or into an array of numbers and then making a loop
> that writes parts of the encoded code into a file and then includes that
> file (this could be made in parts so that only a part of the file is in
> non-encrypted form at a time).
>   This, of course, would stop only the most newbies from getting your code.
> It would not require much knowledge about the pov-script to modify the loop
> a bit so that it writes everything to a file and that's it.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

ryan constantine <rco### [at] yahoocom> writes:

> if you are writing the program that will send it to povray, you could
> make your own encription file that is decoded to a temporary pov file at
> runtime and then erased when the image is done....?

Copying the temporary pov file while POV-Ray is working would be easy.
You could pipe the source code directly to POV-Ray, but again it is
easy to get the code: Simply replace POV-Ray by a script that saves
the file to disk.

As warp already wrote:
"So if povray can get it, then the user can get it as well."
You can only make it a little bit obscure how to get it.

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

Thomas Willhalm wrote:
> 
> As warp already wrote:
> "So if povray can get it, then the user can get it as well."
> You can only make it a little bit obscure how to get it.
> 

Isn't this true for any encryption, though? At varying levels of difficulty, of
course.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

Margus Ramst <mar### [at] peakeduee> wrote:
: Isn't this true for any encryption, though? At varying levels of difficulty, of
: course.

  In this type of cases, yes.
  It's easy to understand with a better example:

  Suppose that you want to distribute an image so that people could only
watch it but not modify it, save it to another format, etc.
  As you can quickly deduce, this is impossible. If the user can watch the
image, he can, for example, take a screenshot of it and save it to whatever
format he likes.
  Even if he couldn't, he could decompile the program that shows the image
to see how does it decrypt the data and then do it by himself (of course this
is a lot more difficult if the program is an executable binary; but in this
case we are talking about an easy-to-understand interpreted scripting
language).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Btw, just for curiosity:
  It might be possible in Windows to create a program that shows an
image which can't be taken a snapshot of: Using DirectDraw to draw the image
directly on screen.
  A snapshot will only get a uniform color designed to that area in the
desktop instead of the image itself. This happens with my TV card. It uses
DirectDraw to show the TV image on screen, but if I try to take a snapshot
of the screen, I only get a magenta square where the TV image should be
(I suppose that this is because the snapshot is not taken directly from
video memory).
  Of course the TV program itself has a snapshot feature to overcome this
problem (I think it takes the image directly from the data sent by the card).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Wasn't it David Vincent-Jones who wrote:
>I am interested in publishing a program that would in turn call upon POV Ray
>to render an output image.
>The image, actually a series of images, would be something like a building
>'walk-through'.
>Is there ant way in which the source .POV file could be encrypted so that
>the user would not have access to this source.
>This problem comes from my potential use of materials that are covered by a
>copywrite, where the copywrite owner dictates that I may freely use and
>publish the material in a final image format but may not divulge the source
>data.... tricky !
>

Wouldn't it also be quite tricky to develop such a system that didn't
violate the terms of povlegal.doc?

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Warp wrote:
> 
>   It might be possible in Windows to create a program that shows an
> image which can't be taken a snapshot of: Using DirectDraw to draw the image
> directly on screen.

The image must still be written to video memory, so if you can read video memory
you can read the image, no? It is quite possible to take screenshots from - say
- DirectDraw games, so in what way would the video display be diffrent?

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

The problem that I am facing is that some of my source data will be
extracted directly from proprietary .dxf files that are currently being
commercially sold.
The only really critical area that would need concealing would be the
<x,y,z> co-ordinates.
Of course I have to convert the data to a .pov script for usage but the data
owner insists that the data must be secured so that the .pov script cannot
be used to reverse engineer the original file.

Post a reply to this message

On Sat, 27 May 2000 10:15:56 -0700, "David Vincent-Jones"
<geo### [at] galaxynetcom> wrote:

>Is there ant way in which the source .POV file could be encrypted so that
>the user would not have access to this source.

Hmm... how about PGP? It's GPL'ed, isn't it? It's just an idea.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

On Wed, 31 May 2000 08:49:09 +0300, Peter Popov wrote:
>On Sat, 27 May 2000 10:15:56 -0700, "David Vincent-Jones"
><geo### [at] galaxynetcom> wrote:
>
>>Is there ant way in which the source .POV file could be encrypted so that
>>the user would not have access to this source.
>
>Hmm... how about PGP? It's GPL'ed, isn't it? It's just an idea.

Actually, PGP isn't GPL'ed.  It's a good example of another famous program
that has available source, but limits the use of that source to versions of
PGP.  At least, that's what I've read.  I've never looked at the PGP source 
license personally.

Also, PGP doesn't solve the problem: the private key the hypothetical 
PGP-POV would use to decode the scene would be encoded somewhere in the
PGP-POV executable.  There are methods to extract crypto keys from binary
data like executables semi-automatically (crypto keys tend to have a 
higher entropy than other binary data) and if that fails one could always
use a debugger to extract the private key.  With the private key known, 
the attacker could easily decode the scene file.

Besides, you'd have to distribute the source to PGP-POV anyway, so all
that reverse-engineering would be unnecessary.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"David Vincent-Jones" <geo### [at] galaxynetcom> wrote in message
news:393002de@news.povray.org...
> I am interested in publishing a program that would in turn call upon POV
Ray
> to render an output image.
> The image, actually a series of images, would be something like a building
> 'walk-through'.

    An extremely slow 'walk-through' ! POV-Ray will not render fast enough
for a real-time walk-through.

    Why not just pre-render the scenes and then 'play' them back in series
to produce the walk-through ?

--
Scott Hill. (sco### [at] innocentcom)
Software Engineer.
Author of Pandora's Box (coming to a web page soon(ish)).

Post a reply to this message

On 29 May 2000 10:31:12 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  Btw, just for curiosity:
>  It might be possible in Windows to create a program that shows an
>image which can't be taken a snapshot of: Using DirectDraw to draw the image
>directly on screen.

I get a kick out of such thoughts.  :)

Being a photographer, I have read of many people trying to protect
their photos when displayed on their website. Sooner or later, someone
finds a way to defeat the computer screen-capture feature and they
assume their image is now secure.

Then someone simply photographs the monitor with a real camera to
capture the image, if they want it badly enough.   :)

Later,
Glen Berry

( Remove the "7" from 7no### [at] ezwvcom to email me. )

Post a reply to this message

On Mon, 29 May 2000 11:10:49 -0700, "David Vincent-Jones"
<geo### [at] galaxynetcom> wrote:

>The problem that I am facing is that some of my source data will be
>extracted directly from proprietary .dxf files that are currently being
>commercially sold.

Do you have written permission to extract and use this data for your
own purpose? The company that owns Poser stopped a few people who
tried to distribute meshes of humans they had created with Poser.

Later,
Glen Berry

( Remove the "7" from 7no### [at] ezwvcom to email me. )

Post a reply to this message

Glen Berry wrote:

> On 29 May 2000 10:31:12 -0400, Warp <war### [at] tagpovrayorg> wrote:
>
> >  Btw, just for curiosity:
> >  It might be possible in Windows to create a program that shows an
> >image which can't be taken a snapshot of: Using DirectDraw to draw the image
> >directly on screen.
>
> I get a kick out of such thoughts.  :)
>
> Being a photographer, I have read of many people trying to protect
> their photos when displayed on their website. Sooner or later, someone
> finds a way to defeat the computer screen-capture feature and they
> assume their image is now secure.
>
> Then someone simply photographs the monitor with a real camera to
> capture the image, if they want it badly enough.   :)
>
> Later,
> Glen Berry
>
> ( Remove the "7" from 7no### [at] ezwvcom to email me. )

Though it would not take care of the 'photo of screen' problem you could write a
small program to take an image interlace it say 4 times ( each of the 4 'frames'
would have 1/4 of the lines and flip through them quickly to appear solid, though
a screen capture would only show one of the 4 frames.

My .02

Post a reply to this message

Glen Berry wrote:
> 
> Sooner or later, someone
> finds a way to defeat the computer screen-capture feature and they
> assume their image is now secure.
> 

I wonder how? As far as I see, you can't really defeat screen-capture,
especially from a web page.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

> The image, actually a series of images, would be something like a
building
> 'walk-through'.

Is the main thing to provide the user with the images or with the ability
to render these images themselves and make their own inputs into the source
file, i.e.
"you fill in the blanks, and the program will spit out a realistic
rendering according to your specification?"
If all the end user needs is images without their own input, then of course
you could render the images and post them to the web and let them sift
their way through them.
I can't see a way to get user input without them being able to see the
source file unless someone programs a patch.  Maybe something that would
work like this -
"include http://something.something.something.com/file.inc"
and then povray uses and processes the file from a website and immediately
destroys it afterwards.  Even then there'd probably be a way around it if
someone were determined.

Post a reply to this message