PanoTools mailing list archive

Mailinglist:PanoTools
Sender:Yuval Levy
Date/Time:2005-Jun-15 19:52:31
Subject:Re: New version of PTViewer

Thread:


PanoTools: Re: New version of PTViewer Yuval Levy 2005-Jun-15 19:52:31
gerdsy wrote:
> Case#1: So lets say that there is a message that is encrpyted with a
> key. A hacker intercepts the encrypted message, but cannot read the
> message because he does not have the key. So he tries to use brute
> force to decode the message.


Yes, *every* encryption method is vulnerable to this sort of attack. It is possible to estimate how long it will take him to succeed, which depends on the key strength and on the available processing power. I vaguely remember a couple of years ago an estimate that to crack current PGP 1024bit keys it would take something like 4000 years (or 4 million? I do not remember, it was just an unreasonably high number). Assuming Moore's law, this has now halved (because processing power has doubled), so it would still take 2000 years. We can double it back to 4000 years by using 2048bit long keys. If the attacker was rich and had 4000 CPUs in a cluster, he could get this cracked in one year. I do not think that this sort of ressources will be thrown against encrypted panoramas in the next few years, unless google decides to put their search engine's hardware to another use.

Time is critical, this is why it is important to change the keys over time.
 
> Case#2: There is a pano that is encrypted so that it can only be
> displayed from a certain url. The pano is viewable BY ANYONE that
> views the pano at that url. So, the pano is already being decrypted by
> EVERYONE that visits the url.


viewable yes. but can it be copied? sure, some idiot could look around in all directions within the applet, print screen them and then try to stitch them again, but the pano would never be as high quality as the original. another risk is that a criminal mind freezes his computer and does a memory dump. there are advanced encryption/decryption techniques that can be used inside the applet to avoid this as well. But what the mechanism currently under discussion really prevents is the simple theft of copying the files form the website and using it without permission.

 
> Do the 2 cases sound the same to anyone?


No, not really. Usage within the applet downloaded from my website is usage with permission. Other usage is usage without permission. Decryption by the applet is controlled. If I make sure that my server only serves the panoramic files to the legitimate applet, I can keep a tab on most threats. Of course an attacker could rewrite the applet using the publicly available source code and try to fool my server to believe that he is the rightful applet, then your Case#2 would materialize. There are ways to avoid this as well, such as checking the applet's signature before sending him the panorama to be displayed, the same way a bank employee checks your identity before giving you information on your account.

Yuv



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/PanoTools/

<*> To unsubscribe from this group, send an email to:
    #removed#

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 




Next thread:

Previous thread:

back to search page