help to convert c++ fonction in python
Toff
I'm trying to convert 2 c++ functions in python
they come from wpkg client
https://wpkg.svn.sourceforge.net/svnroot/wpkg/wpkg-client/Sources/Components/XmlSettings.cpp
they are
CString CXmlSettings::Crypt(CString str)
CString CXmlSettings::Decrypt(CString str)
CAn someone help me?
i d'ont know much about c++
thanks
Tim Roberts
It's possible this solution is a bit too clever.
import base64
import itertools
key = (
0x50, 0xF7, 0x82, 0x69, 0xEA, 0x2D, 0xDD, 0x2D, 0x6A, 0xB4,
0x33, 0x8F, 0xD5, 0xC7, 0x90, 0x9C, 0x22, 0x95, 0x61, 0xE5,
0x65, 0xF6, 0xB0, 0x4B, 0x94, 0x47, 0xB0, 0xBD, 0x73, 0x58,
0x56, 0x87, 0x79, 0x7B, 0xE6, 0xB0, 0xD2, 0x20, 0x28, 0xE1
)
def Crypt( s ):
return base64.encode(
''.join(
chr(ord(x)^y) for x,y in itertools.izip(s,itertools.cycle(key))
)
)
def Decrypt( s )
s1 = base64.decode( s )
return ''.join(
chr(ord(x)^y) for x,y in itertools.izip(s1,itertools.cycle(key))
)
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts
I should have tested before I posted. These work. There is one
significant difference between my code and the C++ original: my code will
not explode if the string to be encrypted is longer than 768 characters.
Theirs will.
key = (
0x50, 0xF7, 0x82, 0x69, 0xEA, 0x2D, 0xDD, 0x2D, 0x6A, 0xB4,
0x33, 0x8F, 0xD5, 0xC7, 0x90, 0x9C, 0x22, 0x95, 0x61, 0xE5,
0x65, 0xF6, 0xB0, 0x4B, 0x94, 0x47, 0xB0, 0xBD, 0x73, 0x58,
0x56, 0x87, 0x79, 0x7B, 0xE6, 0xB0, 0xD2, 0x20, 0x28, 0xE1
)
import base64
import itertools
def Crypt( s ):
return base64.b64encode(
''.join(
chr(ord(x)^y) for x,y in itertools.izip(s,itertools.cycle(key))
)
)
def Decrypt( s ):
s1 = base64.b64decode( s )
return ''.join(
chr(ord(x)^y) for x,y in itertools.izip(s,itertools.cycle(key))
)
s = 'Hello, there'
print s
t = Crypt(s)
print t
u = Decrypt(t)
print s
geremy condra
> http://mail.python.org/mailman/listinfo/python-list
>
For the love of baby kittens, please, please, please tell me that
you do not believe this securely encrypts your data.
Geremy Condra
geremy condra
> On Sat, Oct 17, 2009 at 7:48 PM, geremy condra <deba...@gmail.com> wrote:
>> For the love of baby kittens, please, please, please tell me that
>> you do not believe this securely encrypts your data.
> Can you do better?
>
Trivially. Use AES, 3DES, any standard cryptosystem- there are
literally dozens of excellent, well-studied implementations in
both C++ and Python, and hardware implementations on many
processors.
The cipher listed will fall in a single round of chosen plaintext
attacks or chosen ciphertext attacks, and with a keylength of
40 bytes against a message length of 768 will give me roughly
19 windows on a single encryption. Frequency analysis is
therefore going to be extremely profitable, not to mention
trivially easy.
Geremy Condra
Toff
> On Sat, Oct 17, 2009 at 7:57 PM, David Robinow <drobi...@gmail.com> wrote:
> > On Sat, Oct 17, 2009 at 7:48 PM, geremy condra <debat...@gmail.com> wrote:
> >> For the love of baby kittens, please, please, please tell me that
> >> you do not believe this securely encrypts your data.
> > Yeah, I think it's pretty good.
> > Can you do better?
>
> Trivially. Use AES, 3DES, any standard cryptosystem- there are
> literally dozens of excellent, well-studied implementations in
> both C++ and Python, and hardware implementations on many
> processors.
>
> The cipher listed will fall in a single round of chosen plaintext
> attacks or chosen ciphertext attacks, and with a keylength of
> 40 bytes against a message length of 768 will give me roughly
> 19 windows on a single encryption. Frequency analysis is
> therefore going to be extremely profitable, not to mention
> trivially easy.
>
> Geremy Condra
Thanks a lot Tim !
@Geremy :
this is not a methode to encrypt data
it is more a methode to encode /decode strings
for exemple to store passwords that need to be used by others
programs
yes it 's insecure
but there is no secure way to store password that 's need to be
retrieve
PS : sorry for my english
Thomas
print s
to:
print u
you'll get different results :)
TC
Lie Ryan
if you change:
s1 = base64.b64decode( s )
into
s = base64.b64decode( s )
you'll get the same result again.
Tim Roberts
>
>For the love of baby kittens, please, please, please tell me that
>you do not believe this securely encrypts your data.
The original poster asked to have two C++ functions converted to Python. That's what I did, using the same names as the original. I neither know nor care how they are used, but let us hope the O.P. understands their limitations.
These are roughly as useful as the old ROT13 encoding.
Steven D'Aprano
> For the love of baby kittens, please, please, please tell me that you do
> not believe this securely encrypts your data.
Surely that depends on your threat model?
If you think that the NSA is interested in your data, then no, obviously
they'll break it in probably minutes.
If you're using it to obfuscate (say) dialog strings in a game, so that
game players can't trivially open the data files in an editor and read
ahead, then this may be enough security against your threat model, so the
answer may be "Yes". But that depends on the game -- if there is real
money involved, then probably "No".
"Secure" is not a binary state. It's always "secure against what?". You
might have the latest, most powerful encryption software, but what are
you going to do if the authorities hit your hand with a hammer until you
give up the passphrase? (Figuratively or literally.) If you live in a
country where this is a risk, then your threat model is different and
AES, 3DES or other standard cryptosystems won't make you any more secure
than rot13.
--
Steven
geremy condra
> You wrote:
>>
>>For the love of baby kittens, please, please, please tell me that
>>you do not believe this securely encrypts your data.
>
>
> These are roughly as useful as the old ROT13 encoding.
> --
> Tim Roberts, ti...@probo.com
> Providenza & Boekelheide, Inc.
>
Apologies, I didn't intend to imply that *you* don't know any better,
which I'm sure you do, but rather that the OP probably doesn't.
And always apply ROT13 twice for extra security.
Geremy Condra
Robert Kern
> On Sat, 17 Oct 2009 19:48:46 -0400, geremy condra wrote:
>
>> For the love of baby kittens, please, please, please tell me that you do
>> not believe this securely encrypts your data.
>
> Surely that depends on your threat model?
Well, let's let the OP off the hook immediately. He's just trying to
interoperate with another piece of software that wrote WPKG. So let's put all of
the blame, if any, on the WPKG authors.
I would say that this form of obfuscation is totally inadequate for WPKG's
actual threat model. The WPKG server, which performs unattended software
installation, appears to run with a very high level of privilege in Windows. It
implements its own authentication mechanism to allow low privilege clients to
access it and install software.
It seems like the threat model has a large attack surface for a small
investment. You don't need NSA level attacks here, just a typical hacker's job.
It's certainly not unreasonable for this to be an easier target than social
engineering for a largish payoff (remote software deployment across an entire IT
infrastructure).
But perhaps this might be an acceptable choice if one were familiar with one's
own IT infrastructure and were implementing this oneself, but to distribute this
to other people....
And the thing is, it is actually pretty damn easy to do something standard and
possibly-secure than it is to roll-your-own definitely-insecure system. It
really doesn't buy you anything. There's just no reason to complicate matters.
There is nothing here to justify bad crypto.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
geremy condra
> Steven D'Aprano wrote:
>>
>> On Sat, 17 Oct 2009 19:48:46 -0400, geremy condra wrote:
>>
>>> For the love of baby kittens, please, please, please tell me that you do
>>> not believe this securely encrypts your data.
>>
>> Surely that depends on your threat model?
>
> interoperate with another piece of software that wrote WPKG. So let's put
> all of the blame, if any, on the WPKG authors.
>
True enough. I wrote to the WPKG mailing list and offered to provide
a patch to migrate them to a standard (and reasonably secure)
cryptosystem, but despite a number of enthusiastic replies from board
members, I've heard nothing from anybody with commit access.
> I would say that this form of obfuscation is totally inadequate for WPKG's
> actual threat model. The WPKG server, which performs unattended software
> installation, appears to run with a very high level of privilege in Windows.
> It implements its own authentication mechanism to allow low privilege
> clients to access it and install software.
>
> http://wpkg.org/System_User
>
> It seems like the threat model has a large attack surface for a small
> investment. You don't need NSA level attacks here, just a typical hacker's
> job. It's certainly not unreasonable for this to be an easier target than
> social engineering for a largish payoff (remote software deployment across
> an entire IT infrastructure).
>
> But perhaps this might be an acceptable choice if one were familiar with
> one's own IT infrastructure and were implementing this oneself, but to
> distribute this to other people....
>
> And the thing is, it is actually pretty damn easy to do something standard
> and possibly-secure than it is to roll-your-own definitely-insecure system.
> It really doesn't buy you anything. There's just no reason to complicate
> matters. There is nothing here to justify bad crypto.
>
> --
> Robert Kern
Well said.
Geremy Condra
Aahz
Can't you tell? I'm already doing that!
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Member of the Groucho Marx Fan Club
Mel
> In article <mailman.1683.1255964...@python.org>,
> geremy condra <deba...@gmail.com> wrote:
>>
>>And always apply ROT13 twice for extra security.
>
> Can't you tell? I'm already doing that!
Just don't flaunt the export restrictions by using ROT52.
Mel.
geremy condra
> In article <mailman.1683.1255964...@python.org>,
> geremy condra <deba...@gmail.com> wrote:
>>
>>And always apply ROT13 twice for extra security.
>
> Can't you tell? I'm already doing that!
> --
> Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Sorry, couldn't read it through all the security. Lets try
8 bit RSA and see if that works better.
Geremy Condra
Aahz
s/flaunt/flout/ HTH, HAND ;-)
Gary Herron
>>
>>> For the love of baby kittens, please, please, please tell me that
>>> you do not believe this securely encrypts your data.
>>>
>>
>> These are roughly as useful as the old ROT13 encoding.
>> --
>> Tim Roberts, ti...@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
> Apologies, I didn't intend to imply that *you* don't know any better,
> which I'm sure you do, but rather that the OP probably doesn't.
>
>
> And always apply ROT13 twice for extra security.
>
+1 for "quote of the week"
> Geremy Condra
>
Paul Rudin
> geremy condra wrote:
>> And always apply ROT13 twice for extra security.
>>
> +1 for "quote of the week"
Even if it's at least 30 years old :)
Processor-Dev1l
Ok, what about SHA1? yeah, it is one-way cipher, but it is also all
you need :).
When user inputs the password, password is hashed using SHA1 and
compared with already stored hash, if hashes are the same, password is
correct. You can use this accross your applications and it will always
work the same.
(if someone forgets his password you can always use random generator
to create new one)
geremy condra
Unfortunately, without input from the dev team over there
I can't do much more than bemoan the current situation.
You are right though- while replay attacks would be a
problem it would be much more resistant to attack than
the current system.
Geremy Condra