Dennis Lee Bieber wrote:
> This is after they'd made an 11x14 enlargement of the "stolen"
> print, cleaned it up with a marker, reduced to life size, and etched
> onto printed circuit board to form a mold for making a latex "skin".
> Which, BTW, also fooled the lock.
http://www.diva-portal.or
Dennis Lee Bieber <[EMAIL PROTECTED]> writes:
> This is after they'd made an 11x14 enlargement of the "stolen"
> print, cleaned it up with a marker, reduced to life size, and etched
> onto printed circuit board to form a mold for making a latex "skin".
> Which, BTW, also fooled the lock.
I r
Les Schaffer <[EMAIL PROTECTED]> writes:
> i forget whether gpg can be given a list of files to decrypt. but cuz of
> what we are doing, i still believe we would need to call gpg more than
> once.
Yes, gpg --batch if I remember correctly.
> Fred Lundh's scheme for blanking the passphrase looks go
Paul Rubin wrote:
> gpg is fairly careful about passphrases. Why are you collecting the
> passphrase in the Python app instead of letting gpg handle it?
as i recall we did that because we needed the passphrase more than once,
and didnt want to have to make the users type in something that long
t
Les Schaffer <[EMAIL PROTECTED]> writes:
> keys are on a USB drive key ring. gpg accesses the key ring as needed,
> but in a separate process. and gpg is done with its work early on in our
> app lifetime. comes back at end to encrypt and then app is done.
gpg is fairly careful about passphrases.
Fredrik Lundh wrote:
> Fredrik Lundh wrote:
>
>> a time (if that's possible; if not, you may need to write a custom
>> extension that builds a command string in a C-level buffer, runs the
>> command, and then overwrites the buffer before returning).
myself, i enjoy building C extensions, but woul
Tim Peters wrote:
> Purely accidental -- nothing guaranteed -- details can (& do) change
> across releases. Read obmalloc.c for a tour of the accidents du jour.
cool. thanks for the pointer!
> Not true, so be glad to forget it.
forget what??? ;-)
> A curious possibility: if you do a debug
Paul Rubin wrote:
> GC simply releases the memory for other uses in the application. It
> doesn't necessarily zero the memory.
release is followed by some probability of eventual overwrite; check.
>
> Just what attack are you trying to protect against, if swap space is
> less of a problem t
Fredrik Lundh wrote:
> Les Schaffer wrote:
>
> > i am working on a python application that uses encryption as part of its
> > security features. so then at some point someone has to enter a
> > passphrase into the system and passed into a decryption functions (we
> > are using gpg via subprocess).
Fredrik Lundh wrote:
> a time (if that's possible; if not, you may need to write a custom
> extension that builds a command string in a C-level buffer, runs the
> command, and then overwrites the buffer before returning).
on the other hand, subprocess seems to support the buffer interface, so
Les Schaffer wrote:
> i am working on a python application that uses encryption as part of its
> security features. so then at some point someone has to enter a
> passphrase into the system and passed into a decryption functions (we
> are using gpg via subprocess).
>
> so i am curious. so long as
[Aahz]
>> Assuming you're talking about CPython, strings don't really participate
>> in garbage collection. Keep in mind that the primary mechanism for
>> reaping memory is reference counting, and generally as soon as the
>> refcount for an object goes to zero, it gets deleted from memory.
[Les S
Les Schaffer <[EMAIL PROTECTED]> writes:
> understood, i meant best practice in terms of the less rigorous garbage
> collection. if the collect() function hastens garbage collection for
> unreferenced strings like a passphrase, it costs us nothing and buys us
> a wee bit.
GC simply releases the me
Aahz wrote:
> Assuming you're talking about CPython, strings don't really participate
> in garbage collection. Keep in mind that the primary mechanism for
> reaping memory is reference counting, and generally as soon as the
> refcount for an object goes to zero, it gets deleted from memory.
ok s
In article <[EMAIL PROTECTED]>,
Les Schaffer <[EMAIL PROTECTED]> wrote:
>
>so i am curious. so long as i drop all reference to the passphrase
>string(s), eventually it gets garbage collected and the memory recycled.
>so "before long" the phrase is gone from memory.
Assuming you're talking about C
Paul Rubin wrote:
> You can't rely on anything like that, either on the Python GC side or
> from the OS (which might have long since written the passphrase out to
> the swap disk) without special arrangement.
we offered to disable swap for this app (its not memory intensive) but
this level of p
Les Schaffer <[EMAIL PROTECTED]> writes:
> so i am curious. so long as i drop all reference to the passphrase
> string(s), eventually it gets garbage collected and the memory recycled.
> so "before long" the phrase is gone from memory.
>
> is there a best practice way to do this?
You can't rely o
2006/8/30, Les Schaffer <[EMAIL PROTECTED]>:
> is there a best practice way to do this?
I'm not a cryptographer, but you should really try the function
collect() inside the gc module.
--
Felipe.
--
http://mail.python.org/mailman/listinfo/python-list
i am working on a python application that uses encryption as part of its
security features. so then at some point someone has to enter a
passphrase into the system and passed into a decryption functions (we
are using gpg via subprocess).
so i am curious. so long as i drop all reference to the pass
19 matches
Mail list logo
