rotor alternative?

R

Robin Becker

[QUOTE="Paul Rubin said:
Quite. I don't understand why it's deprecated. We've known since the
fifties that the algorithm is broken, so wasn't it clear from the
start that this was for obfuscation, not strong encryption? Shouldn't
we just add a warning to the docs (if there's not one there already)??

No. Using weak cryptographic algorithms for obfuscation should itself
be deprecated. If there's a need to obfuscate something, that means
that somebody is trying to read it when you don't want them to, and
the correct countermeasure is real encryption, not obfuscation.[/QUOTE]
You're probably right, but given that the code itself has to unobfuscate
to make use of the data then any key/algorithm etc has to be present
somewhere.

How should we obfuscate? Using a crypto function just increases the time
and effort that someone needs to get the plain text. Likewise using a C
extension makes it harder for the casual thief. The professional won't
be bothered.

The rotor module was small and speedy. In my case I'm sure that it makes
very little difference to use base64 and a xor or something similar.
When we really want data to be protected we're using one time passwords
assigned by a special server.
 
D

Dave Brueck

Peter said:
That's kind of the heart of the matter right there: just how good _is_
rotor, compared to modern algorithms?

I disagree, I don't think that's the issue at all. Rotor is far, far weaker
than even DES, but both take far, far more effort to crack than practically
anyone is willing to put forth, and I don't tend to care about that 0.0001% of
the people who do want to invest the effort.
My guess is that it's so insecure that most people wouldn't really want
to use it if they knew how insecure it was, or they would actually decide
that something like XORing the data is actually adequate and stick with
that.

Maybe so, maybe not. Here's one counter data point: me. :) FWIW, rotor isn't
_that_ much more complicated that XORing your data, the main difference being
that the data you XOR it with changes after each byte. Probably the bulk of the
benefit of rotor is that it's present, documented, and maybe that it's in C so
it's fast.

If someone is trying to protect their data but haven't done enough of their
homework to know that rotor versus e.g. AES is incredibly weak, odds are they
aren't going to have a secure system *at all* anyway, no matter how strong
encryption library they use - they'll probably leave the key totally exposed or
some such mistake. If a person using it _doesn't_ know how insecure it is, then
even if you give them AES to make the front door impenetrable, most likely all
the windows will still be wide open.
I suspect that those who want rotor actually want something stronger
than it really is, but could actually get by with something even weaker
than it is (though they don't believe that), and leaving it out of the
standard library isn't a real problem, just a perceived one.

How's this: it would be really great to have a key-based data obfuscator (read:
weak encryptor) ship as a standard part of Python. I'll concede that if rotor
keeps somebody out, a simple data munge like XOR probably would too (although
you're getting a little closer to the point where hex editor-using crackers can
play whereas rotor requires a programmer cracker). The difference is that a
standard module like rotor hits the sweet spot in terms of diminishing returns
of effort vs security, so if you're going to settle for that level of security
and have it ship as a standard module, why _not_ just use rotor?

-Dave
 
P

Paul Rubin

Robin Becker said:
You're probably right, but given that the code itself has to unobfuscate
to make use of the data then any key/algorithm etc has to be present
somewhere.

The idea of cryptography now is to keep the data secure as long as the
key is secret. It's ok if the algorithm is known. If the key is known
too, all bets are off.
How should we obfuscate? Using a crypto function just increases the time
and effort that someone needs to get the plain text.

If you can keep the key secret and the cryptography is any good, there
should be no way for anyone to break the cryptography without the key.
Rotor fails in that criterion.
Likewise using a C
extension makes it harder for the casual thief. The professional won't
be bothered.

I think you're underestimating the technical ability and determination
of amateurs on the internet. Look at all the virus writers out
there--who is paying them? Almost every day Microsoft has to release
a new critical security patch because of some weakness that got
exploited by a non-professional and caused users a lot of hassle. The
exploit usually isn't some technical breakthrough on the attacker's
part, but rather stems from an attitude problem at Microsoft, that
their products only have to be secure enough to make it "harder for
the casual thief" since "the professional won't be bothered". That is
precisely the wrong attitude to have, as we see every time Microsoft
announces that "as of today security is our #1 priority" and then goes
back to doing the same dumb stuff, and a few days later, yet another
virus brings everyone's work to a halt yet another time. If you're
going to use cryptography at all, use it as well as you can.
The rotor module was small and speedy. In my case I'm sure that it makes
very little difference to use base64 and a xor or something similar.

Using base64 or an xor should be even smaller and speedier than rotor,
so if that's your goal, the answer is still "use xor and get rid of
rotor". The only reason to use rotor instead of xor is you think xor
isn't secure enough. But if xor isn't secure enough, you should use
real cryptography, not rotor.
When we really want data to be protected we're using one time passwords
assigned by a special server.

If you really want data to be protected I hope whatever methods you're
using were designed or at least reviewed by someone who knows what
they're doing. That's not intended as a put-down toward you; there
are a lot of mistakes that get made over and over again, and it takes
some knowledge and experience to recognize them and not make them.
Using something like rotor is very frequently an example of such a mistake.
 
A

Aaron Watters

Deprecation is a very serious matter. I love the Python language but
I have questions about the deprecation decisions.

Yea, random changes can do a lot of damage. Examples
repr(string) went hex and broke a lot of stuff for interacting
with systems that matched the old octal representation
(pdf format for example). It's very hard to ferret out all
the places where someone assumed that chr(0)=="\000".
cgi.environ disappeared and broke every cgi script in the CD
ROM in my python book right after it hit the shelves. :(!
regex was used pervasively. Why not just provide a translator stub
rather than deprecate it (noting in the documentation that it's
slower)? More examples on request...
arrgh. Please don't break code for cosmetic reasons!
-- Aaron Watters
===
I can't do that, Dave.
 
D

Dave Brueck

Peter said:
That's kind of the heart of the matter right there: just how good _is_
rotor, compared to modern algorithms? Can anyone describe it perhaps
in comparison with DES/3DES using a kind of "equivalent key size" estimate?

Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis, its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).

For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing
power that can crack a single intercepted message using a brute force approach
(because cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several times the
length of the key).

Obviously you could use the face-to-face meeting to exchange a CD of AES keys
to use, but each intercepted message would, in theory, be open to a brute force
attack, unless every AES-bitKeyLength/8 bytes of the message were encrypted
with a new key from the CD, but it would be far more expensive
computationally - using "modern" encryption algorithms is just a trade off
because for many appications CPU cycles are an abundant resource. But there do
exist situations where you are CPU constrained, so it may be a good tradeoff
for e.g. an embedded device with limited CPU to use a rotor-like algorithm and
its own ROM as the key.

Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.

(I'm not suggesting that we should be using rotor everywhere, just pointing
that it has some cool properties and isn't totally useless nowadays. :) )

-Dave
 
P

Paul Rubin

Offense taken :(. Please explain (offline if you like).
It's okay to call my stuff awful, but I require a bit of
constructive criticism to go with it.

I don't want to spend time analyzing the algorithms when there are
already perfectly good ciphers available and it's better to just stick
with them. But without making any real attempt to figure out what
your cipher is doing, several things are immediately obvious:

1) There is no attempt to provide any randomness in the output. If
you encrypt the same plaintext twice with the same key, you get the
same ciphertext. That is a security failure in many applications.

2) What's more, the cipher is a one-character-at-a-time stream cipher
so if you encrypt two different plaintexts that begin with a common
prefix, it looks to me like the ciphertexts will also have a common
prefix, another security failure.

3) No authentication is provided. An attacker who intercepts a
ciphertext in transmission can change it and the decryption side
will have no idea that anything has happened. All kinds of real-world
systems have made that same mistake and suffered for it.

4) It's almost certain that the cipher is vulnerable to
related-key attacks (as RC4 is), and from the way the cipher
feedback works, it may be easy to spot related plaintexts
(not just common prefix) by looking at the ciphertext.
FWIW it was loosely inspired by RC4 and it seems to scramble
things up nicely.

Being loosely inspired by RC4 is unreassuring on several grounds.

First of all, RC4 was designed very carefully by a knowledgeable
cryptographer who did a lot of studies and statistical experiments on
RC4 variants before settling on RC4. Don't be fooled by RC4's
simplicity, since just about every attempt to tweak it has in fact
made it worse. If you want an RC4-like cipher, use RC4, not a
"loosely-inspired" home-cooked variant that hasn't withstood a lot of
cryptanalysis attempts.

Second, RC4 itself doesn't have such good properties. RC4 can only be
used securely if key selection and authentication are done properly,
which takes knowledge. Take a look at IEEE 802.11 WEP to see what
happens if you use RC4 improperly but still in a way a reasonable
non-stupid engineer might expect it to work. The
Fluhrer-Shamir-Mantin attack uses RC4's internal structure to break
WEP with a very limited amount of captured traffic. Since WEP is
deployed in millions of Wifi cards, corporations all over the place
are spewing secret data over their wireless networks where they can be
intercepted by any malicious cretin driving past their building with a
wifi-equipped laptop. WEP would be much more secure if it had used
AES instead of RC4.

Third, even if RC4 is used properly, there are distinguishing attacks
that can tell that the RC4 keystream is not random given a few
gigabytes (maybe a lot less). That itself can be a security failure
in some applications like encrypting a hard drive. RC4 really
shouldn't be used in new applications. Use AES instead.
Regarding speed: for small blocks it should
be reasonably fast for a pure python module which doesn't
use any extension modules, and it is also suitable for conversion
into a very small self contained C function, which was the intent.

But yours is much faster of course, since it uses an extension module
for the critical loop. For larger blocks more than an order of
magnitude faster.

Coding either of those algorithms as a C function would be a big
mistake. Once you have a way to use C functions, it's better to use
AES. However, coding RC4 in pure Python should run about midway
between Pulverizer and p3 in speed.
The two are not precisely comparable, I think, because as far as I can
tell you just encrypt a single string, whereas mine encrypts a sequence
of strings progressively, unless I'm missing something.

Yes correct, p3.py encrypts a single string like rotor does. Bryan
Olson did a reference implementation of an earlier version of p3, that
can be used for stream encryption. It's in this post:

http://groups.google.com/[email protected]
 
P

Paul Rubin

repr(string) went hex and broke a lot of stuff for interacting
with systems that matched the old octal representation
(pdf format for example). It's very hard to ferret out all
the places where someone assumed that chr(0)=="\000".

repr really shouldn't be used that way though.
 
P

Paul Rubin

Dave Brueck said:
Just as a semi-off-topic followup, rotor-like algorithms still have
some situations that make them more attractive than modern
algorithms. While rotor _is_ much weaker on an "equivalent key size"
basis, its computational simplicity makes it feasible to use
extremely large keys without additional CPU costs, so that you can
end up with a much _higher_ degree of security per CPU cycle spent
in encryption / decryption if there is a way for both sides to agree
on extremely large keys (and there are plenty of ways to do that).

But the internal state of the rotor system has fixed size, no matter
how long the key is. In the case of the Python rotor module, that
size is 10 bytes, though of course there are much better attacks than
brute force search.
For example, suppose you and I have a monthly face-to-face meeting,
so we use that as an opportunity to swap CDs of random data. It is
feasible for us to use _the entire CD_ as an encryption key (yay, a
6 billion bit key!) and, assuming the data is sufficiently random,
there is literally _no_ amount of computing power that can crack a
single intercepted message using a brute force approach (because
cracking part of the key doesn't yield you info on any other part of
the message until you have intercepted messages totalling several
times the length of the key).

In that case we can just use the random cd as an additive one-time pad
and have no need for rotor algorithms. Note that we won't get any
authentication either way.
Obviously you could use the face-to-face meeting to exchange a CD of
AES keys to use, but each intercepted message would, in theory, be
open to a brute force attack,

But in fact the likelihood of such an attack is much lower than the
likelihood of the CD itself getting intercepted by an attacker. Really,
this stuff gets rehashed on sci.crypt almost every week, it gets boring
after a while.
But there do exist
situations where you are CPU constrained, so it may be a good
tradeoff for e.g. an embedded device with limited CPU to use a
rotor-like algorithm and its own ROM as the key.

There are much better algorithms than rotor even for tiny cpu's.
Skipjack, for example, needs only about 3 bytes of scratch ram on an
8-bit cpu while any reasonable rotor cipher needs far more than that.
Also, with rotor errors in the key cause only localized damage in
the data stream,

Several of the standard block cipher chaining modes have the same property.
so if the application consuming the decrypted data can recover from
a small error rate, you can use some pretty crazy sources for your
keys: with a little work you could e.g. encrypt live telephone
conversations with the satellite video feed of CNN (with the
telephony application running the feed through a filter to reduce
noise and extract a reliable subset of the feed and then
synchronizing off of, say, the closed caption data). If somebody
knows that you're using that as your key source then they can crack
your message, but otherwise an intercepted message is safe from
brute force attacks.

But that's silly, you have to assume that your attacker knows what
methods and key sources you're using (Kerchoff principle). If you
can't securely exchange a shared secret key beforehand, the solution
is to use a public-key key agreement algorithm with locally generated
random data at each end, not crazy crap like digitizing a CNN feed.
(I'm not suggesting that we should be using rotor everywhere, just
pointing that it has some cool properties and isn't totally useless
nowadays. :) )

But it really is totally useless nowadays, unless you want an insecure
system.
 
L

Lulu of the Lotus-Eaters

(e-mail address removed) (Aaron Watters) wrote previously:
|FWIW it was loosely inspired by RC4 and it seems to scramble
|things up nicely.

For cryptography, "inspired by" is a very bad standard. Very small
changes to algorithms can hugely lessen their strength. Moreover,
"seeming to scramble" is almost worthless--good algorithms need
literally years of serious study by very good cryptographers before even
minimal assurances of strength can be made.

Yours, Lulu...

--
mertz@ | The specter of free information is haunting the `Net! All the
gnosis | powers of IP- and crypto-tyranny have entered into an unholy
..cx | alliance...ideas have nothing to lose but their chains. Unite
| against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------
 
P

Paul Rubin

Peter Hansen said:
That's kind of the heart of the matter right there: just how good _is_
rotor, compared to modern algorithms? Can anyone describe it perhaps
in comparison with DES/3DES using a kind of "equivalent key size" estimate?

That's not really a sensible question to ask. The WW2 Enigma machine,
for example, had much more key space than DES/3DES, but it was
vulnerable to cryptanalytic attacks that were far more effective than
brute force. Rotor itself looks to have been written quite
carelessly. It's basically a bunch of linear-congruential PRNG's
which are notoriously weak as ciphers.
My guess is that it's so insecure that most people wouldn't really want
to use it if they knew how insecure it was, or they would actually decide
that something like XORing the data is actually adequate and stick with
that.

It's best to go with that assumption even if breaking rotor is
actually a bit harder.
I suspect that those who want rotor actually want something stronger
than it really is, but could actually get by with something even weaker
than it is (though they don't believe that), and leaving it out of the
standard library isn't a real problem, just a perceived one.

Actually it's the other way, lots of people think they can get by with
rotor or with something weaker, when they really need something
stronger. Leaving rotor IN the standard library is a real problem.
 
P

Paul Rubin

Dave Brueck said:
Maybe so, maybe not. Here's one counter data point: me. :)

May I ask what application you want to use rotor for?
If someone is trying to protect their data but haven't done enough
of their homework to know that rotor versus e.g. AES is incredibly
weak, odds are they aren't going to have a secure system *at all*
anyway, no matter how strong encryption library they use - they'll
probably leave the key totally exposed or some such mistake. If a
person using it _doesn't_ know how insecure it is, then even if you
give them AES to make the front door impenetrable, most likely all
the windows will still be wide open.

Having spent a lot of time as the in-house crypto maintainer on a
security-intensive commercial development project, I can confirm that
there's much truth to what you're saying. That's why a built-in
library encryption function intended for non-specialists has to free
the application programmer as much as possible from the likelihood of
using a cipher the wrong way. Of course there's infinite ways the
application itself can screw something up, but the library implementer
can't much help that.
How's this: it would be really great to have a key-based data
obfuscator (read: weak encryptor) ship as a standard part of
Python.

But that's precisely what rotor is, and IMO it does a bad job.
I'll concede that if rotor keeps somebody out, a simple data munge
like XOR probably would too (although you're getting a little closer
to the point where hex editor-using crackers can play whereas rotor
requires a programmer cracker). The difference is that a standard
module like rotor hits the sweet spot in terms of diminishing
returns of effort vs security, so if you're going to settle for that
level of security and have it ship as a standard module, why _not_
just use rotor?

If you're going to ship something as a standard module, it should try
to provide real security. It was a mistake to have ever shipped rotor.
 
A

A.M. Kuchling

Hmmm... the more I think about it I guess the root cause of the problem is the
archaic, goofy encryption export laws of the U.S.. If Python could ship with

s/of the U.S./of various countries/ and you'd be correct. See the
python-dev thread starting at
http://mail.python.org/pipermail/python-dev/2003-April/034957.html . I
originally deprecated rotor with the goal of getting an AES module into 2.3.
The objection was then raised that having crypto produces legal hassles in
various countries, so the idea of an AES module was shot down but rotor was
deprecated anyway as one step to removing it.

(Arguably this is inconsistent with distributing SSL support in binary
versions of Python. No one has suggested removing SSL support from the
source code, but MAL did suggest removing it from the default Windows
installer.)

--amk
 
P

Paul Rubin

A.M. Kuchling said:
http://mail.python.org/pipermail/python-dev/2003-April/034957.html . I
originally deprecated rotor with the goal of getting an AES module into 2.3.
The objection was then raised that having crypto produces legal hassles in
various countries, so the idea of an AES module was shot down but rotor was
deprecated anyway as one step to removing it.

This is unfortunate, especially since it's so simple to implement
strong cryptography with the already-existing modules like SHA.

Maybe there needs to be a crypto and a non-crypto distribution.
That's what was done for both Netscape and MSIE for years, under the
old US export restrictions. For Python nowadays, it will be easier,
since the problem isn't exporting from Python's central distribution
point, but rather with importing into certain repressive regimes. So
it's not required for the distribution point (as long as it's in a
free country) to try to enforce any restrictions on downloading
cryptography, as Netscape and Microsoft formerly had to do. It can
just provide two links (crypto and non-crypto) and let the user
download whatever they want.

I also continue to urge inclusion of a secure random number generator
in the Python library, per the technical discussions we've already
had about how to do that. I don't think that would count as cryptography.
 
P

Paul Foley

Just as a semi-off-topic followup, rotor-like algorithms still have some
situations that make them more attractive than modern algorithms. While rotor
_is_ much weaker on an "equivalent key size" basis,

It isn't. The WWII Enigma machine with 3 rotors and 10 plugboard
pairings has a "pure brute force" strength of ~88.8 bits (~98.4 bits
for the 4 rotor version) -- that's more than 4 billion times stronger
than DES :)

It has a major statistical weakness, though, in that no letter can
encode to itself.
its computational
simplicity makes it feasible to use extremely large keys without additional CPU
costs, so that you can end up with a much _higher_ degree of security per CPU
cycle spent in encryption / decryption if there is a way for both sides to
agree on extremely large keys (and there are plenty of ways to do that).

I'm not sure how the rotor module works, but AFAIK it's just some
variant on the basic Enigma theme -- in which case, the real key
length is fixed (e.g., in real Enigma, the selection of rotors
installed, their initial positions, and the plugboard settings), so
whatever it does with the key you pass in to generate the internal
state, you can't increase the strength by using a longer key.

I had a quick look at rotormodule.c -- the internal key consists of 5
16 bit values (and it looks like they're not independent of one another)
so it wouldn't be worth using a key longer than about 60 characters
even if it was a "strong" cipher.
For example, suppose you and I have a monthly face-to-face meeting, so we use
that as an opportunity to swap CDs of random data. It is feasible for us to use
_the entire CD_ as an encryption key (yay, a 6 billion bit key!) and, assuming
the data is sufficiently random, there is literally _no_ amount of computing

If you were going to do that, you should just use XOR against the data
on the CD. Using rotor in this situation can only make an attack
possible.
Also, with rotor errors in the key cause only localized damage in the data
stream, so if the application consuming the decrypted data can recover from a
small error rate, you can use some pretty crazy sources for your keys: with a
little work you could e.g. encrypt live telephone conversations with the
satellite video feed of CNN (with the telephony application running the feed
through a filter to reduce noise and extract a reliable subset of the feed and
then synchronizing off of, say, the closed caption data). If somebody knows
that you're using that as your key source then they can crack your message, but
otherwise an intercepted message is safe from brute force attacks.

Want to bet?
 
A

Aaron Watters

Paul Rubin said:
(e-mail address removed) (Aaron Watters) writes:>
I don't want to spend time analyzing the algorithms when there are
already perfectly good ciphers available and it's better to just stick
with them.

Yes, I agree. Thanks for taking the time.
1) There is no attempt to provide any randomness in the output...
2) What's more, the cipher is a one-character-at-a-time stream cipher
so if you encrypt two different plaintexts that begin with a common
prefix, it looks to me like the ciphertexts will also have a common
prefix, another security failure.
3) No authentication is provided....
4) It's almost certain that the cipher is vulnerable to
related-key attacks...

Since the input is fed into the encryption mechanism adding random
garbage bytes to the input every so often in a predictable manner will
address 1,2,4. Adding any sort of checksum will address 3. This is
the kind criticism I enjoy! thanks again.
Being loosely inspired by RC4 is unreassuring on several grounds...

I agree completely with the rest. -- Aaron Watters
===
The cup holder on my computer is broken.
 
P

Peter Hansen

Paul said:
Actually it's the other way, lots of people think they can get by with
rotor or with something weaker, when they really need something
stronger. Leaving rotor IN the standard library is a real problem.

Maybe it's both. :) Obviously at least some of the people here
don't think they can get by with less, and yet it seems increasingly
likely that they actually could, given that all that has been asked for
is "obfuscation". (If the goal is to prevent accidental or casual
observation from revealing information, almost anything (like an XOR)
should be good enough. Anything more needs something that shouldn't
be called "obfuscation", IMHO.)

I guess the point is then that rotor is in a dangerous middle ground,
where it looks better than it really is. Either way it's the wrong
thing for someone to use, whether they want strong or weak encryption.

-Peter
 
P

Paul Rubin

Peter Hansen said:
I guess the point is then that rotor is in a dangerous middle ground,
where it looks better than it really is. Either way it's the wrong
thing for someone to use, whether they want strong or weak encryption.

Yes, that's a good summary.
 
J

John J. Lee

Paul Rubin said:
But that's precisely what rotor is, and IMO it does a bad job.

That's not a "but", that's an "and". It does a bad job of strong
encryption, it does the job for obfuscation. It *is* a step up
Anybody can write a program to decrypt XORed data in a line of code
(maybe emacs has a keystroke for it), decryption of rotor encryption
requires the extra effort to find a library to crack it, or to know
enough to write your own. Whether that small point justified its
initial inclusion is certainly debatable, but now it's in there, it
seems like a mistake to deprecate it.


John
 
J

John J. Lee

Paul Rubin said:
No. Using weak cryptographic algorithms for obfuscation should itself
be deprecated. If there's a need to obfuscate something, that means
that somebody is trying to read it when you don't want them to, and
the correct countermeasure is real encryption, not obfuscation.

First, not necessarily, if you're in a country that has legislation
controlling strong encryption (and yes, we know "that should be
fixed", but sadly we don't have that power ;-). Second, if you have
to have the key around anyway (true for some applications), it really
doesn't matter how secure the algorithm is.

Obfuscation is a perfectly sane thing to want to do, and rotor is just
a way of making reading data mildly more of a PITA than XOR. I don't
think even emacs has a decrypt-rotored-text function <0.5 wink>.


John
 
J

Jorge Godoy

That's not a "but", that's an "and". It does a bad job of strong
encryption, it does the job for obfuscation. It *is* a step up
Anybody can write a program to decrypt XORed data in a line of code
(maybe emacs has a keystroke for it), decryption of rotor encryption
requires the extra effort to find a library to crack it, or to know
enough to write your own. Whether that small point justified its
initial inclusion is certainly debatable, but now it's in there, it
seems like a mistake to deprecate it.

Sorry for my ignorance, but how do you get to decrypt the code to run?
Use any kind of wrapper? Is such a wrapper written in C? Do you store
the key inside such a wrapper?

The same problem would happen with AES or any other crypt method:
where and how to store the key in a way that's easy for the user.


See you,
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top