Werner Koch:
On Fri, 27 May 2011 10:48, jer...@jeromebaum.com said:
There is still a compression step by default though, right? I know gzip has
Right. I forgot to mention that. Unless gpg figures that the data is
already compressed, it will be compressed before encryption.
Or unless
On Fri, 27 May 2011 10:48, jer...@jeromebaum.com said:
There is still a compression step by default though, right? I know gzip has
Right. I forgot to mention that. Unless gpg figures that the data is
already compressed, it will be compressed before encryption.
Salam-Shalom,
Werner
--
On Fri, 27 May 2011 00:04, gro...@caseyljones.net said:
volume. The advantage of those is that a single bit error is likely to
only affect one file. If you archive the files before transferring
FWIW, it is the same as with OpenPGP. The used CFB mode re-syncs after
soon after the bad block.
On Fri, May 27, 2011 at 10:09, Werner Koch w...@gnupg.org wrote:
On Fri, 27 May 2011 00:04, gro...@caseyljones.net said:
volume. The advantage of those is that a single bit error is likely to
only affect one file. If you archive the files before transferring
FWIW, it is the same as with
In the future, instead of GPG or OpenSSL I would suggest an encrypted
filesystem such as an encrypted folder or partition or Truecrypt volume.
The advantage of those is that a single bit error is likely to only
affect one file. If you archive the files before transferring them to
your
On 17 maj 2011, at 14.52, Jerome Baum wrote:
On Tue, May 17, 2011 at 14:16, Turbo Fredriksson tu...@bayour.com
wrote:
But the last part didn't end up at the 64 char limit the other lines
have. Instead, the last
char on that line is at position 15. Would that be a problem?
It doesn't sound
On Thu, May 19, 2011 at 11:46, Turbo Fredriksson tu...@bayour.com wrote:
On 17 maj 2011, at 14.52, Jerome Baum wrote:
On Tue, May 17, 2011 at 14:16, Turbo Fredriksson tu...@bayour.com wrote:
But the last part didn't end up at the 64 char limit the other lines have.
Instead, the last
char
On Tue, 17 May 2011 00:35, jer...@jeromebaum.com said:
were made for different purposes and I think you're stretching GPG very far
if you want to encrypt big streams of data. That's more something OpenSSL
As a Unix tool GPG is designed to work on arbitrary data lengths. The
problem is mereley
On 16 maj 2011, at 18.35, Jerome Baum wrote:
So, start at the beginning of scrapped data (with a copy, of
course), fill in As until you reach the 76 (or 80) limit, fill in
a line break, continue with As, repeat until nothing left.
That was a lot more difficult than it sounded!! :)
I tried
On Tue, May 17, 2011 at 14:22, Turbo Fredriksson tu...@bayour.com wrote:
On 16 maj 2011, at 21.11, Jerome Baum wrote:
On Mon, May 16, 2011 at 19:08, Turbo Fredriksson tu...@bayour.com wrote:
I've locked at some encrypted FS's, but none of them where secure enough.
In what sense? Can you
On Tue, May 17, 2011 at 14:16, Turbo Fredriksson tu...@bayour.com wrote:
But the last part didn't end up at the 64 char limit the other lines have.
Instead, the last
char on that line is at position 15. Would that be a problem?
It doesn't sound good but just go ahead and try. How long does a
I now managed to find the problematic line(s).
archive1.0280
5470206000 d0 00 ad de d0 00 ad de d0 00 ad de d0 00 ad de
5470207000 d1 00 ad de d1 00 ad de d1 00 ad de d1 00 ad de
These are the only lines I've found so far...
Now, what does this mean?! :)
--
Build a man a fire, and he will be
On Mon, May 16, 2011 at 14:04, Turbo Fredriksson tu...@bayour.com wrote:
I now managed to find the problematic line(s).
archive1.0280
5470206000 d0 00 ad de d0 00 ad de d0 00 ad de d0 00 ad de
5470207000 d1 00 ad de d1 00 ad de d1 00 ad de d1 00 ad de
These are the only lines I've found so
On 16 maj 2011, at 15.46, Jerome Baum wrote:On Mon, May 16, 2011 at 14:04, Turbo Fredriksson tu...@bayour.com wrote: I now managed to find the problematic line(s).archive1.02805470206000 d0 00 ad de d0 00 ad de d0 00 ad de d0 00 ad de 5470207000 d1 00 ad de d1 00 ad de d1 00 ad de d1 00 ad deThese
On Mon, May 16, 2011 at 17:32, Turbo Fredriksson tu...@bayour.com wrote:
Now, I tried to just remove the binary chars, but that ended up with a line
which is shorter than the others which I doubt will work (it would take me
almost a day to find out - slow USB1 disks), so any idea on how to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi
On Monday 16 May 2011 at 1:04:33 PM, in
mid:5a6acd14-1b72-439f-adb4-c28cd6751...@bayour.com, Turbo
Fredriksson wrote:
Build a man a fire, and he will be warm for the
night. Set a man on fire and he will be warm for the
rest of his life.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
El 16-05-2011 12:35, Jerome Baum escribió:
...
In the worst case, you may be looking at loosing everything from the
corruption point onwards, assuming some kind of stream compression. This
is IIRC the default for GnuPG when it encrypts. Otherwise
*bump*
Begin forwarded message:
I needed to move lots of data from one site to another across
europe. I got a huge disk and archived all data onto that using
something like (simplified):
find | cpio -o | gpg -e | split - /disk/archive.
To extract the data again, it's just as simple:
On Fri, May 13, 2011 at 11:55, Turbo Fredriksson tu...@bayour.com wrote:
*bump*
Begin forwarded message:
But this last one gave me a problem when trying to unpack
it:
gpg: invalid radix64 character D0 skipped
gpg: invalid radix64 character 00 skipped
gpg: invalid
On 13 maj 2011, at 12.08, Jerome Baum wrote:
1. What character is D0, 00, AD and DE? What can I look for
(to try to diagnose the problem/file)
You can look for D0, 00, AD and DE.
Doh! I assumed that these where some code characters (meaning it's
something else in the actuall file).
On Fri, May 13, 2011 at 12:42, Turbo Fredriksson tu...@bayour.com wrote:
On 13 maj 2011, at 12.08, Jerome Baum wrote:
1. What character is D0, 00, AD and DE? What can I look for
(to try to diagnose the problem/file)
You can look for D0, 00, AD and DE.
Doh! I assumed that these where
21 matches
Mail list logo
