On Dec 5, 2007 1:06 PM, Robert J. Hansen [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
a simpler, much faster, solution is to just use truecrypt
and then encrypt the keyfile with gnupg
Unless you have done performance metrics with 1TB datasets, I seriously
doubt the accuracy of this
On Nov 26, 2007 3:58 AM, Thomas Pries [EMAIL PROTECTED] wrote:
I realized, that I have lost my data :-(.
Our solution for backup encyption has been to use 7zip, since it
encrypts faster and supports segmentation, per-file checksuimming, and
other useful backup-oriented features.
What our
Snoken wrote:
is the old problem with files greater than 4 GB solved? How large
files can gpg handle on WindowsXP? On other systems?
My recollection is that the file size issue was fixed years ago, as it
was a limitation in the MinGW layer or something that was remedied. I
never followed up
On Nov 2, 2007 10:52 AM, David Shaw [EMAIL PROTECTED] wrote:
The new OpenPGP standard has been published. It was assigned RFC
number 4880 (someone at the IETF has a sense of humor):
Is there an FAQ or other document which highlights only the changes
and improvements since 2440? The output of
You advocate a
(x) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it
won't work. (One or more of the following may apply to your particular
idea, and it may have other flaws which used to vary from state to
state before a
On 10/18/07, Robert J. Hansen [EMAIL PROTECTED] wrote:
With proprietary software, you're mostly stuck relying on your vendor
for information. Compare Microsoft says that IIS will scale up to our
server load with our current server configuration to the Apache
Foundation isn't making any
On 10/15/07, gabriel rosenkoetter [EMAIL PROTECTED] wrote:
It's up o the site administrator to make use of SA rules that aren't
braindamaged. It's hardly the fault of the authors of SA if some
site decides to add 2.5 points to every message with a MIME
attachment, though you can, perhaps, see
On 9/6/07, Oskar L. [EMAIL PROTECTED] wrote:
One thing I forgot to mention in that discussion, is that since DSA is the
default, there are probably many more DSA keys in use currently than RSA
keys. (If anyone has any statistics that would be interesting to see.)
Therefore, if a government
On 6/19/07, Henry Hertz Hobbit [EMAIL PROTECTED] wrote:
than it took me to tar it. It also takes me much less time to
encrypt the tarred file than it takes to do the final bzip2 of the
encrypted file.
Huh? Why would you try to use bzip2 AFTER encrypting?
Strongly-encrypted data is not
On 5/17/07, Andrew Berg [EMAIL PROTECTED] wrote:
Aren't optical discs supposed to last for many decades if stored
properly and almost never used?
Theory and practice are often far apart. The price of CD media has
dropped so low that quality is often an issue. CDfreaks has many
articles about
On 5/17/07, Alessandro Vesely [EMAIL PROTECTED] wrote:
Not quite. That may happen as an undocumented side effect on some
(or all) OS versions, and is not what the function is meant to do.
The function keeps the page in memory. The OS is still free to back
it up whenever it thinks it is
On 5/16/07, Peter Todd [EMAIL PROTECTED] wrote:
Then only that
passphrase needs to be securely stored and the secret key can be stored
with standard backup procedures.
I believe the originally posted question centered around long-term key
storage, for which magnetic and optical media are
On 5/15/07, Alessandro Vesely [EMAIL PROTECTED] wrote:
Virtual memory is a feature that an OS can expose to apps. Memory mapped
files are an example. On Linux there are both shm and mmap. Traditional
SysV stuff may better suit inter-process sharing, while more recent APIs
emphasize
On 5/15/07, Casey Jones [EMAIL PROTECTED] wrote:
There appears to be an open source project going for PDF417
http://en.wikipedia.org/wiki/PDF417
We've used PDF417 for conference attendee badges in the past. They
work well, and there seems to be quite a bit of hardware and software
out there to
On 5/14/07, Zach Himsel [EMAIL PROTECTED] wrote:
On 5/14/07, Peter S. May [EMAIL PROTECTED] wrote:
On Linux, swap space is its own partition
I just realized something. You have the option to NOT use swap
space in Linux. Does this mean that there is no memory written
to disk? If so, then it
On 5/14/07, Peter S. May [EMAIL PROTECTED] wrote:
(Developers familiar with swap-locked memory: I'd appreciate at least a
short explanation of how it works to someone who understands ISO C but
not necessarily OS-specific APIs. Can stack memory be locked, or only
heap memory? Would there be
On 4/18/07, Anders Breindahl [EMAIL PROTECTED] wrote:
However, I assume you know what you talk about, when you say that we
aren't likely to factor 256-bit-numbers ever. So please restate that --
even in the face of quantum computers -- we won't ever factor 256 bit
numbers.
By the way, I
On 11/2/06, Henry Hertz Hobbit [EMAIL PROTECTED] wrote:
7-zip, like most zip programs encryption doesn't even come close
to the level of protection that you are getting with GnuPG. Even
if you are using the lowest level cipher GnuPG provides, it is a
quantum leap over the zip programs
On 10/17/06, Nicholas Cole [EMAIL PROTECTED] wrote:
--- Ryan Malayter [EMAIL PROTECTED] wrote:
Again I must state that one has little to do with
the other. MHTML's
MIME format may not play nice with PGP/MIME's
encapsultation format,
but it didn't *have* to be that way. S/MIME
On 10/17/06, Mica Mijatovic [EMAIL PROTECTED] wrote:
...
There is no any whimsicality in it (the previous message and wider) and
the answers/observations are given quite sternly and with a quite fine
necessary precision.
...
It's like reading Ulysses, but as a day in the life of Richard
On 10/16/06, Mica Mijatovic [EMAIL PROTECTED] wrote:
RFCs are not any standards nor they are by (their own) definition
supposed to be.
They are just collection of less or more recommended routines, and often
also nothing but the lists of (most usual/mass) _habits_.
Many RFCs *are* standards.
On 10/14/06, Werner Koch [EMAIL PROTECTED] wrote:
Anyway, HTML mails are evil.
But unfortunately they're here to stay. RFC 2557 is now listed as
standards track.
I used to rail against HTML mail myself, but all my reasoning was
soundly rebuffed by the CEO, CFO, my Mom, my sister, and really
HTML + OpenPGP = FAIL.
In English: HTML screws up OpenPGP. You don't want it. There are other
reasons why you don't want HTML anyway but I won't go into them here.
Actually, when I sign an HTML email with GPGOL, and send it to my
Gmail account, I seem to get this on the receiving end:
1) A
On 9/24/06, Qed [EMAIL PROTECTED] wrote:
I haven't seen much traffic on ietf-openpg mailing list about this
issue, maybe the last message about ECC was in 2001.
ECC is not a priority task for RCF2440, do you think this statement is
more acceptable?
As far as I know, Certicom and others control
On 4/7/06, John M Church [EMAIL PROTECTED] wrote:
Qed/Ryan et al,
Do either of you guys do automated decryption? This doesn't seem to be
addressed in the FAQ - just automated signing. I'm open to suggestions.
I do use GnuPG for automated decryption for one batch process. To do
so, I use a
On 4/2/06, Qed [EMAIL PROTECTED] wrote:
Different implementations = different speeds.
You cannot rely on a particular piece software to infer general
performance figures for crypto algos.
This is very true. In my tests, for example, AES implementation in
GnuPG runs far slower than the
On 1/21/06, Johan Wevers [EMAIL PROTECTED] wrote:
If speed isn't an issue, why would anyone prefer rar over bzip2? Bzip2
compresses much better than rar anyway, although it's slow.
Bzip2 does not compress better than RAR or LZMA, at least with my test corpus.
See
On 11/9/05, Philipp Kern [EMAIL PROTECTED] wrote:
Yeah, I got that fact. So to clarify: A USB token with a supported
smartcard in it.
I don't know if they are supported by GnuPG, but we have several of
the Aladdin eToken devices bundled by PGP Corp. with PGP Desktop v9.
They work fairly well
On Fri, 2005-10-07 at 10:07 +0800, nidhog wrote:
Do you guys have any suggestion as to how to go about encrypting a
partition that can be available both to linux and win32?
Why not use a hardware solution, so it sits underneath the OS
entirely? Seagate makes a new laptop drive that has built-in
On 9/20/05, Werner Koch [EMAIL PROTECTED] wrote:
I have to commit that I did not try larger files on Windows for years
(lack of disk space) so here might indeed be a problem with that. A
quick check however shows that GetFileSize is used correctly.
Werner, I can confirm that large file ( 4GB)
On 8/10/05, Alphax [EMAIL PROTECTED] wrote:
How long will 8 characters (standard unix password length) take to break
at present?
Using the supplied figure of 200 keys per second, and using only the
95 printable ASCII characters:
(95^8)/200 seconds. Or about 1.1 million years!
Obviously, if you
On 8/4/05, Werner Koch [EMAIL PROTECTED] wrote:
So roughly libgcrypt gets 55% of the performance of OpenSSL with AES
and 61% for 3DES. This all with a higher level interface, a non ia32
optimized AES. I am pretty sure we can improve here but it will
require to duplicate code for the modes
On 8/3/05, Henry Hertz Hobbit [EMAIL PROTECTED] wrote:
Given the size of the files that you are encrypting, I would strongly
advise going with the Eden chip rather than a software based solution...
I actually found an open-source tool, 7-zip, that includes AES-256
encryption functionality. For
I was going to use GnuPG for encrypting some very large backup files
on disk (~200 GB). However, the symmetric ciphers in GnuPG seem to be
fairly slow. Using the Windows build of 1.4.2, I only modest
throughputs piping GPG output from a fast 7200 RPM disk to NUL (the
Windows equivalent of
=k3Rn= wrote:
Is it possible to specify a min password length (maybe
entropie) from that on the password can be considered 'safe' against
bruteforcing?
The password length has little to do with the amount of entropy it
contains.
See this old thread:
[Alex L. Mauer]
Can you expand on this?
How could the Name/address/ssn be retrieved from a hash of the same?
The data can be recovered from the hash because search space is small.
Say you are looking for the SSN of a John Smith. Every large DB is bound
to have someone named John Smith.
[Jean-David Beyer]
Aside from the necessity to compromise the machine running
gpg to get the
timing data for this attack,
just how much data can a timing attack retrieve from a
multiprogramming
system, such as UNIX, Linux, etc., anyway, since all the
other processes
running at the same
[Per Tunedal Casual]
2) Are any other ciphers safer to this kind of attack? What about the
ciphers in OpenPGP applications? Other AES candidates?
From my reading of it, it looks like any cipher with data-dependent
S-boxes would seem to be susceptible to this class of attack. I think
that
38 matches
Mail list logo
