I don't know if you guys have seen Andrew K's page on Cryptographic Curiosities... But it shouldn't be too hard to include for instance the RSA algorithm in Zope, when it can be expressed in four lines of Python: #!/usr/local/bin/python from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!= '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce( lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1))) According to his example, it can be used like this: echo 'Top secret message.' | rsa.py 10001 1967cb529 > ciphertext cat ciphertext | rsa.py -d ac363601 1967cb529 Fuller description can be found on http://starship.skyport.net/crew/amk/writing/crypto-curiosa.html (And just out of curiosity: Is it a crime to view this web page outside the US? ;) -- Magnus Lie Hetland www.pvv.org/arcadia <arcadia@pvv..org>
In our meetings at work, if discussion appears to be bogging down, any participant can say "This is a rat-hole" to end the discussion, meaning roughly "This topic can be debated endlessly without coming to any resolution." Cryptography often winds up being such a rat-hole, and this discussion seems equally unlikely to be productive. I'm not convinced it's a huge issue for Zope users; do competing products such as Cold Fusion or Frontier support security at all if the Web server doesn't have it? Magnus Lie Hetland writes:
I don't know if you guys have seen Andrew K's page on Cryptographic Curiosities... But it shouldn't be too hard to include for instance the RSA algorithm in Zope, when it can be expressed in four lines of
A crude implementation of RSA is one thing; actually implementing SSL -> X.509 -> PKCS is entirely another. You'd be better off looking at Pat Knight's UK-based SWIGging of SSLeay, and finishing it off if you're outside of the US. That would be really useful, both for Python in general and Zope in particular. (Someone on the python-crypto mailing list reported that they actually finished SWIGging all of SSLeay's functions; unfortunately they're in the US...)
(And just out of curiosity: Is it a crime to view this web page outside the US? ;)
I hope not! Seriously, those 4 lines of code aren't really usable cryptographic systems, so I don't believe that anyone would try to apply export controls to them. -- A.M. Kuchling http://starship.skyport.net/crew/amk/ Here you come again with your arithmetical conundrums, when I am suffering death with a cold in the head. -- Mark Twain
On Wed, 30 Dec 1998, Andrew M. Kuchling wrote:
In our meetings at work, if discussion appears to be bogging down, any participant can say "This is a rat-hole" to end the discussion, meaning roughly "This topic can be debated endlessly without coming to any resolution." Cryptography often winds up being such a rat-hole, Agreed. and this discussion seems equally unlikely to be productive. I'm not convinced it's a huge issue for Zope users; do competing products such as Cold Fusion or Frontier support security at all if the Web server doesn't have it? Hmmm. Does the competition (NT) run stable for more than some hours under heavy load? So why should Linux run stable?
Nope that's not the way it's done with free software ;) (Actually I mean technical sound software in comparision to software where marketodroids have the saying *g*, which happens to apply often to free software.)
A crude implementation of RSA is one thing; actually implementing SSL -> X.509 -> PKCS is entirely another. You'd be better off looking at Pat Knight's UK-based SWIGging of SSLeay, and finishing it off if you're outside of the US. That would be really useful, both for Python in general and Zope in particular. (Someone on the python-crypto mailing list reported that they actually finished SWIGging all of SSLeay's functions; unfortunately they're in the Hmmm. What about printing it, the swig code should not be to much?
Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
On Thu, Dec 31, 1998 at 12:09:06AM +0100, Andreas Kostyrka wrote:
[ Flame bait deleted ] Nope that's not the way it's done with free software ;) (Actually I mean technical sound software in comparision to software where marketodroids have the saying *g*, which happens to apply often to free software.)
If you want it, write it, and then I'll be happy to put my cryptographer's hat on (didn't you wonder what I did for money?) and rip it to shreds... the reality is that at this point, in this poltical climate, with the current available resources, it's just not an intellegent move. Security (of which cryptography may or may not be a component of) is a highly complex topic often bantered around by marketing people, and almost never understood by anyone who uses the word. THe only thing worse than no security is the false sense of SOME security (ney, Windows NT and it's "C2" certification---without a floppy or network, or many other things). You need to define WHAT you're trying to accomplish before you reach into the toolbox and pick a tool, rather than swing about your hammer-de'jour looking for anything that might stick out, and calling it a nail. Cryptography is a grand thing, a mathematical tour-de-force if done correctly, BUT it's rarely the issue. If all you ahve to worry about is whether someone can break your 40-bit key by brute force, you've done a handy job, but don't delude yourself into thinking that even relevant to most discussions. The concept of "role based" authentication in ZOPE is wonderful as a first step, there are many more that need to be made... all in good time, as technology and time permit. I would love ot see a fully trusted, multi-level secure object publishing system, but given we can't even get a secure WEB SERVER, I'm not holding MY breath for another minute. One must ask the question, "what are you protecting" and "what is it worht".... so long as the aggregate of what you protect and it's value is less than the effort required to counter your protections, you have succeeded in building a reasonably secure system. The world is about risk-mitigation, not about absolute security, the latter does not, can not, will not exist, ever, even the NSA understands this concept. Define a risk, identify it's threat points, mitigate them through use of (policy, technology, whatever) and move on. If you can not mitigate the risk, you must understand and accept it. That's the business. Also, we need to understand the distinction between trust (behaving the way you are expected to), and security which is a more general principle. Chris -- | Christopher Petrilli | petrilli@amber.org
On Wed, 30 Dec 1998, Christopher G. Petrilli wrote:
On Thu, Dec 31, 1998 at 12:09:06AM +0100, Andreas Kostyrka wrote:
[ Flame bait deleted ] Nope that's not the way it's done with free software ;) (Actually I mean technical sound software in comparision to software where marketodroids have the saying *g*, which happens to apply often to free software.)
If you want it, write it, and then I'll be happy to put my Ok. Let's take my asbesto pants, and start to play a bit fire dep. ;)
Ok, this whole threat started, with someone noticing that: -) He likes his editor, -) He likes to use his standard project management tools, -) Basically, he doesn't like BoboPOS. Ok, I responded that it's not to difficult to achieve very many benefits of a Zopesque development without BoboPOS ;) The crypto stuff came into play when someone tried to sell the planned FTP interface as a replacement, and I mentioned that I do not like to send plaintext passwords over the Internet. Especially not if the password ``means'' something like the ability to edit a website. (A password to access some paysite may be ok to send in cleartext. That depends upon your goals ;) ) Now to summerize my only ``difference'' with the Z Zen ;). Z uses BoboPOS to activate/deactivate objects. IMHO, this is one of the shortcut hacks, that make Python what it is. *g* I strongly prefer to have an explicit activation/deactivation. Why? Because this much stronger spells out what is stored/done/etc. in the object, compared to some implicit activation/deactivation. Additionally, I prefer to use more ``traditional'' storage forms (kind of HTML documents usually belong onto a filesystem, or into a document managment system, ``data'' belongs into a SQL system.), I know this is pain in the beginning, but in the long run it's got the best maintainibility.
cryptographer's hat on (didn't you wonder what I did for money?) and rip it to shreds... the reality is that at this point, in this poltical climate, with the current available resources, it's just not an intellegent move. I've never suggested that I want seriously implement such a beast. I'm quite happy with BoboHTTPServer running on internal loopback alias, protected by some additional levels of paranoia ;), being served to the world by Apache/SSL ;)
Before I found the ``solution'' (hack is probably the better naming) with Apache/mod_rewrite/mod_proxy/BHS, I've considered (not too seriously) to use SSLeay to enhance BHS. Knowing that I'm not a crypto guru *g* (they teach here around not to much crypto to CS majors :( ), I'd considered much more strongly to patch pcgi to work better to my liking ;)
Security (of which cryptography may or may not be a component of) is a Correctly. I'd just rather say, that with an unsecure communication channel, cryptography is rather a good idea (I know S/key, etc., but it's all in some way poor substitute to secure channel, isn't it?)
highly complex topic often bantered around by marketing people, and almost never understood by anyone who uses the word. THe only thing worse than no security is the false sense of SOME security (ney, Windows Actually, NT3.51 in a patched version was C2, without floppy, CDs, network, etc. Actually, some people suggest that after the some architectural changes in NT4, it isn't possible for NT4 to achieve the C2 even with the funny restrictation 3.51 had, ... But MS has some trolls on the NTSEC mailing list, that keeps singing the mantra: NT is safe. NT is safe. No matter what other people tell them *g*
NT and it's "C2" certification---without a floppy or network, or many other things). Exactly my point. I'm not sleeping to well, as I'm responsible for some servers on the Internet. To put it bluntly. I consider myself relativly capable to provide for security on my ``own'' (administered by myself) boxes and LANs, but I'd never go advertising myself as a security consultant. Especially as I know at least one guy that has his ads run in some national publications as security consultant, and we know that the only achievment of this guy in this field are: -) configuring his companies firewall in a funny way, so that transmitting files from the internal network to servers outside the firewall is only possible by sending email :( (Not by intend, but by gross missunderstanding of TCP/IP). -) Being hacked at least once a month on his web server. Actually I'd rather say, that he notices it once a month, there are just no statistics about the unnoticed breakins ;) )
So I'm quite wary of security experts, being it individuals or companies. But I managed to manage (or co-manage) Linux (and for a short time HP/UX, but that were unexposed boxes) boxes on the Internet for 6 years, without being hacked to often. Actually it happened once on my home box with modem dialup, and since then I've learned that even Modem dialup boxes that come in contact with the Internet have to be secured properly.
You need to define WHAT you're trying to accomplish before you reach That's quite easy. (Actually you are right, it's not that easy.)
-) Running websites without exposing the server to hacking, even considering that it is located in a highrisk area of the net (colocated at a ISP on one huge ethernet segment, and the ISP seems not to have a policy against turning one's ethernet device into promiscious mode, ...) -) Asorted other typical tasks. Again without being compromised. At the moment my biggest headache is POP, as it insists on cleartext passwords, and requiring clients to use ssh tunnels doesn't work to well, as I don't like the idea of shell access for untrusted people to much. So is the mission goal clear enough.
into the toolbox and pick a tool, rather than swing about your hammer-de'jour looking for anything that might stick out, and calling it a nail. Cryptography is a grand thing, a mathematical tour-de-force if done correctly, BUT it's rarely the issue. If all you ahve to worry Not really. As outlined, using an unsecure communication channel, ``security'' becomes VERY HARD to achieve without cryptography. And the Internet is an insecure channel. Admittingly it comes in different shades, ranging from threat area to insanely high threat area. (Actually, I've got one private box I manage on the internet in a segment where the main admin has a laissez-faire mentality. Actually he likes to collect all the nice tools the hackers leave on his servers, he only gets sometimes upset, because the hackers leave some CPU intensive processes running, etc. Still my box hasn't been hacked. Admittingly the box doesn't run much except apache and sshd *g*)
about is whether someone can break your 40-bit key by brute force, Actually, I'm quite happy with 40-bit keys for website editing. The point is to get rid of sniffers. What I like less are 40-bit keys when authenticating for a root shell, but then it'd probably do the trick too. The point is that if there is enough crypted traffic, the real bad guy have much more to decrypt ;) you've done a handy job, but don't delude yourself into thinking that even relevant to most discussions.
The concept of "role based" authentication in ZOPE is wonderful as a first step, there are many more that need to be made... all in good time, as technology and time permit. I would love ot see a fully trusted, multi-level secure object publishing system, but given we can't What do you mean exactly by trusted, multi-level? even get a secure WEB SERVER, I'm not holding MY breath for another When you mean by trusted, multi-level, secure WEB SERVER something that supports UP-write, DOWN-read policies and level separation, I'd rather say you are on lost ground, as http as such doesn't support that to well.
minute. One must ask the question, "what are you protecting" and "what is it worht".... so long as the aggregate of what you protect and it's value is less than the effort required to counter your protections, you have succeeded in building a reasonably secure system. *nod* But now let's consider virtual website hosting. These sites quite possibly could contain: -) personal data. We've got stupid laws about protecting personal data here arounds. Beside all the hassle, not complying with these stupid (actually, personally I consider this law much to mild, but that's the theoretical point) law is punished by around USD20000 per incident, ... Now explain to someone that you did not sell the data, that it was stolen. (Every data processing facility have to be able to explain how it got the personal data and how it acquired it legally, but I personally tend to provide my personal data often with spelling mistakes and have a list which mistake was provided where *g*) -) credit card numbers. I don't know what the credit card companies would do to us, but I'm pretty sure, I would not like it much. And one thing is sure. They have more money for lawyers. While we have more fair and sane judicary process here around than in the land of freedom, it tends still to be a deciding factor. (Ok, if someone wants to discuss this claim, explain to me how one can be a murderer, and not be one at the same time? It's probably my shallow training in logic as a CS major which makes me having problems to accept a calcule that defines (A and not A) as true ;)
-) medical personal information. I'm about to lauch some sites for clients where doctors will be publishing but also counceling patients. Don't think that having your data base of medical inquiries (x@isp.at: Hi, my brother does have AIDS and I'd like to ask, ...) stolen is a ``good thing''.
The world is about risk-mitigation, not about absolute security, the latter does not, can not, will not exist, ever, even the NSA understands this concept.
Absolutly. In my case I just observe: -) https (even the bastardized NSA approved key length version) greatly improves the security. (against the threat of sniffing, which in my experience (of six years working with the Internet) is quite often the first breach of usage policies. -) https is extremely cheapily to implement. It basically costs: a bit of CPU usage. (With my current hardware, I'll have enough possibilities to upgrade horsepowers. Coming from a P100 ANYTHING today is really fast.) If there is a need of a separate certificate, it's about 125USD or so. For editing websites it's obviously not mandatory to do it under the same URL. It's probably ok to edit http://www.xyz.com as https://www.isp.com/xyz/ :) The situation may be different in the states, where RSA is patented, but here around it's quite cheap :) Andreas -- Win95: n., A huge annoying boot virus that causes random spontaneous system crashes, usually just before saving a massive project. Easily cured by UNIX. See also MS-DOS, IBM-DOS, DR-DOS, Win 3.x, Win98.
On Thu, Dec 31, 1998 at 04:50:15AM +0100, Andreas Kostyrka wrote:
The crypto stuff came into play when someone tried to sell the planned FTP interface as a replacement, and I mentioned that I do not like to send plaintext passwords over the Internet. Especially not if the password ``means'' something like the ability to edit a website. (A password to access some paysite may be ok to send in cleartext. That depends upon your goals ;) )
I agree that "identification" is an important goal, the whole concept of reusable identification tokens (ney passwords) is counter to any normal security ideology. This however, is the best we can do with what's out ther in many people's hands, so it should remain. That doesn't mean we shouldn't work harder to produce something else more capable for those who desire/need it, and who can support the ncessary infrastructure (see below).
Now to summerize my only ``difference'' with the Z Zen ;). Z uses BoboPOS to activate/deactivate objects. IMHO, this is one of the shortcut hacks, that make Python what it is. *g*
I'd not call it a hack, but that's irrelevent.
I strongly prefer to have an explicit activation/deactivation. Why? Because this much stronger spells out what is stored/done/etc. in the object, compared to some implicit activation/deactivation.
This to me is counter to the principle of persistent storage of objects. I'm sure Jim would be more than happy to expound on how it IS explicit at some level, perhaps you just want more control over THAT level, which is an entirely different question.
Additionally, I prefer to use more ``traditional'' storage forms (kind of HTML documents usually belong onto a filesystem, or into a document managment system, ``data'' belongs into a SQL system.), I know this is pain in the beginning, but in the long run it's got the best maintainibility.
This has been discussed elsewhere and is ignored for this discussion.
cryptographer's hat on (didn't you wonder what I did for money?) and rip it to shreds... the reality is that at this point, in this poltical climate, with the current available resources, it's just not an intellegent move. I've never suggested that I want seriously implement such a beast. I'm quite happy with BoboHTTPServer running on internal loopback alias, protected by some additional levels of paranoia ;), being served to the world by Apache/SSL ;)
THis currently is about the "best" as one can do... but read on, the future isn't as bleak as one might think... with a little understanding of what's possible.
Before I found the ``solution'' (hack is probably the better naming) with Apache/mod_rewrite/mod_proxy/BHS, I've considered (not too seriously) to use SSLeay to enhance BHS. Knowing that I'm not a crypto guru *g* (they teach here around not to much crypto to CS majors :( ), I'd considered much more strongly to patch pcgi to work better to my liking ;)
The core of the problem comes from where you want "authentication" to happen... if it's at the web server level, and you trust that, then that's cool, it can be done using the current system, but if you want something stronger, it's necessary to rethink how authentication credentials are handled/verified.
Security (of which cryptography may or may not be a component of) is a Correctly. I'd just rather say, that with an unsecure communication channel, cryptography is rather a good idea (I know S/key, etc., but it's all in some way poor substitute to secure channel, isn't it?)
As is often the case, people confuse privacy with other things. Encrypting the channel is only one factor, to me it's more imporatnt to protect the identification stage, which is a different issue than the privacy fo the information. While this is also an issue (as perhaps could be non-repudiation and tamper-detection), it's a different one, and honestly trivial to solve... the identification problem is the complex one.
So I'm quite wary of security experts, being it individuals or companies. But I managed to manage (or co-manage) Linux (and for a short time HP/UX, but that were unexposed boxes) boxes on the Internet for 6 years, without being hacked to often. Actually it happened once on my home box with modem dialup, and since then I've learned that even Modem dialup boxes that come in contact with the Internet have to be secured properly.
The core to good security is an understanding of risk management, threat analysis and policy development, anything else avoids the necessary understanding of the underlying issues, and simply throws a blanket over them.
You need to define WHAT you're trying to accomplish before you reach That's quite easy. (Actually you are right, it's not that easy.)
-) Running websites without exposing the server to hacking, even considering that it is located in a highrisk area of the net (colocated at a ISP on one huge ethernet segment, and the ISP seems not to have a policy against turning one's ethernet device into promiscious mode, ...)
Impossible, someone's always smarter than anyone else can be. You can mitigate the risk and make it unattractive so hackers move elsewhere, but you can NOT eliminate the risk for any sum of money---short of unplugging the machine. Period, end of story.
-) Asorted other typical tasks. Again without being compromised.
Again, see above about risk mitigation. People need to learn to think in the concepts of risk containment and mitigation, and not absolutes. Absolutes do not exist.
So is the mission goal clear enough.
Clear as mud, still... avoid stating things so vaguely... Are you concerned with privacy or authentication more? If so, what restrictions are you willing to place on the user to support it? Digest authentication would HELP (a small amount), but it's not supported last I checked in Netscape or IE or Opera.
``security'' becomes VERY HARD to achieve without cryptography.
Define security in this context. Cryptography comes in many forms, hash algorithsm are all you need for dealing with the basics of identification, block/stream ciphers are used for privacy (I know, let's not get into the details of symetric crypto signing systems).
And the Internet is an insecure channel. Admittingly it comes in different shades, ranging from threat area to insanely high threat area.
Different PARTS of the Internet are different. I'd argue that the threat from the INSIDE of someone's backbone is an order of magnitude less than the risk from someone on your own segment, or nearby. All surveys and analysis indicates that 80% of threats are internal, not external.
about is whether someone can break your 40-bit key by brute force, Actually, I'm quite happy with 40-bit keys for website editing. The point is to get rid of sniffers. What I like less are 40-bit keys when authenticating for a root shell, but then it'd probably do the trick too. The point is that if there is enough crypted traffic, the real bad guy have much more to decrypt ;)
Key rotation, etc., eliminate this as a concern... The size of keys protecting national security assets is much smaller than people think. They're just rotated a LOT. Again, the issue is, are you worried about people seeing what you're doing, or are you worried about someone DOING something... passive/active attack situation.
you've done a handy job, but don't delude yourself into thinking that even relevant to most discussions.
The concept of "role based" authentication in ZOPE is wonderful as a first step, there are many more that need to be made... all in good time, as technology and time permit. I would love ot see a fully trusted, multi-level secure object publishing system, but given we can't What do you mean exactly by trusted, multi-level?
Trusted = behaves according to design Multi-level = compartmentalization of data into distinct "bubbles" that are isolated from one-another. Control is implemented to prevent data floating between layers except in one direction (up).
even get a secure WEB SERVER, I'm not holding MY breath for another When you mean by trusted, multi-level, secure WEB SERVER something that supports UP-write, DOWN-read policies and level separation, I'd rather say you are on lost ground, as http as such doesn't support that to well.
The point is that there are billions of threat vectors in the system, it's necessary, before going all out concentrating on one or another, to understand which is most important and most vunerable to the kind of compromise you are most worried about.
minute. One must ask the question, "what are you protecting" and "what is it worht".... so long as the aggregate of what you protect and it's value is less than the effort required to counter your protections, you have succeeded in building a reasonably secure system. *nod* But now let's consider virtual website hosting.
This is a nefarious ugly bastard child concept :-)
These sites quite possibly could contain: -) personal data. We've got stupid laws about protecting personal data here arounds. Beside all the hassle, not complying with these stupid (actually, personally I consider this law much to mild, but that's the theoretical point) law is punished by around USD20000 per incident, ... Now explain to someone that you did not sell the data, that it was stolen. (Every data processing facility have to be able to explain how it got the personal data and how it acquired it legally, but I personally tend to provide my personal data often with spelling mistakes and have a list which mistake was provided where *g*)
Anyone who uses shared resources to store this information has violated the "good faith" clause of most laws, and at least in the US would be liable regardless of the other steps they might have taken.
-) credit card numbers. I don't know what the credit card companies would do to us, but I'm pretty sure, I would not like it much. And one thing is sure. They have more money for lawyers. While we have more fair and sane judicary process here around than in the land of freedom, it tends still to be a deciding factor. (Ok, if someone wants to discuss this claim, explain to me how one can be a murderer, and not be one at the same time? It's probably my shallow training in logic as a CS major which makes me having problems to accept a calcule that defines (A and not A) as true ;)
Again, similar problems. The key to processing CC information is to toss the information "over the wall" into another system which is not generally publically acessible. For example, in a previous life, I built a processing system that tossed PO information through a serial port to a DOS machine on the other side ... could have been NT or whatever. This was a one-way trip, and you couldn't get the information back. Retrieval of this information was restricted to console access, and physical measures were implemented to protect this.
-) medical personal information. I'm about to lauch some sites for clients where doctors will be publishing but also counceling patients. Don't think that having your data base of medical inquiries (x@isp.at: Hi, my brother does have AIDS and I'd like to ask, ...) stolen is a ``good thing''.
This is something to talk to a lawyer about, as there are all kinds of seperation issues that have to be maintained in various legal areas... this is a difficult one like all the above, to answer... but I think they're all irrelevent in "shared" environments because they all violate the "good faith" clause...
The world is about risk-mitigation, not about absolute security, the latter does not, can not, will not exist, ever, even the NSA understands this concept. Absolutly. In my case I just observe: -) https (even the bastardized NSA approved key length version) greatly improves the security. (against the threat of sniffing, which in my experience (of six years working with the Internet) is quite often the first breach of usage policies.
It's still a 6 character password, no matter how much you encrypt it... the only viable solution for this is public-key certifications (client certificates), which provide orders of magnitude more strength. They also provide all kinds of neato side-effects for site customization because once they are presented you can refer to all kinds of info in the LDAP directory that's generally used to store them. Unfortionatly, no "free" web server support them, and no commercial one is worth a damn...
-) https is extremely cheapily to implement. It basically costs: a bit of CPU usage. (With my current hardware, I'll have enough possibilities to upgrade horsepowers. Coming from a P100 ANYTHING today is really fast.) If there is a need of a separate certificate, it's about 125USD or so. For editing websites it's obviously not mandatory to do it under the same URL. It's probably ok to edit http://www.xyz.com as https://www.isp.com/xyz/ :)
Again, see above... Again, I just wanna get this targeted at the underlying issues, rather than "solutions"... solutiuons are obvious if you understand the problem. Chris -- | Christopher Petrilli | petrilli@amber.org
On Wed, Dec 30, 1998 at 03:53:59PM +0100, Magnus Lie Hetland wrote:
I don't know if you guys have seen Andrew K's page on Cryptographic Curiosities... But it shouldn't be too hard to include for instance the RSA algorithm in Zope, when it can be expressed in four lines of Python:
#!/usr/local/bin/python from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!= '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce( lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))
Just because you can doesn't mean you should :-) I played with this at one point (and some other things I implemented in Python for "research") and it was all SEVERAL orders of magnitude slower than RSA's BSAFE package... to the point of unusability for any real work.
(And just out of curiosity: Is it a crime to view this web page outside the US? ;)
Yes, and technically it's against the law for this message to enter the US and then exit it... I deal with ITAR on nearly a daily basis, as my company is a relatively big player in the crypto world... It's not pretty ,and I don't recommend getting involved if you can avoid it. I don't think privacy is as much a concern as authentication, and MD5 is fully exportable, as is DSA (which is better).... It's not always necessary to insure ALL aspects of security. Chris -- | Christopher Petrilli | petrilli@amber.org
participants (4)
-
Andreas Kostyrka -
Andrew M. Kuchling -
Christopher G. Petrilli -
Magnus Lie Hetland