[Box Backup] out-of-the-blue CipherException?
Matto Marjanovic
maddog at mir.com
Sat Apr 14 23:14:35 BST 2012
On 04/12/12 01:12, Chris Wilson wrote:
> On Wed, 11 Apr 2012, Matto Marjanovic wrote:
...
> I have added some extra debugging code to the trunk, which will
> hopefully help to identify the faulty filename and its
> container. Please could you try downloading and building the latest
> code from trunk, and run a test backup with it, using the -DV
> option, to see if it does find anything useful?
...
Done, and yes, it helped to identify the subdirectory, though not so
much the particular file. The directory is in a cyrus mailspool, many
levels deep, with hundreds of files. Log output is appended at the end.
I added some additional output of my own: the binary block which failed
to be decrypted, and the preceding block which was successfully decrypted
(in case that would help predicting what comes next).
Anyhow: armed with this information, what now?
Also: where do I find the blowfish key? I figure I should be able to
run those little 8-byte blocks through openssl and see how they fail or
succeed, right?
>> In the meantime, could you perhaps elaborate on the nature of the
>> problem a bit more? I got as far into the code as figuring out that
...
> The server has a filename stored on its disk, in one of the directory
> files, which the client can't decrypt. The client needs to decrypt
> all filenames in a directory on the server to know whether it needs
> to create a new one for a local file that didn't exist before, update
> an existing one keeping history, or delete one that no longer exists
> on the client.
>
> The corruption might originally have happened on either the server or
> the client, probably while the directory was in memory a neutrino
> struck a RAM chip and flipped one of the bits, and the corrupted name
> was written back out to disk on the server.
Sure, blame the hapless (and almost massless) neutrinos.
Even if not due to a bug (and I'm not convinced it's the act of elementary
particles just yet), the failure mode is pretty heinous. There's got to be
a reasonable way to recover from such an error.
Heh... in fact: if it is indeed a one-bit cosmic-ray induced error, I should
be able to flip the 64 bits in the binary block one at a time until I get
something that decodes successfully! I'll try that out (once I get a pointer
on how/where to extract the key).
-m
ps: The tail of the log output:
TRACE: Obtained 10 stack frames.
TRACE: Stack frame 0: DumpStackBacktrace()+0x22
TRACE: Stack frame 1: CipherContext::TransformBlock(void*, int, void const*, int)+0x9bb
TRACE: Stack frame 2: BackupStoreFilenameClear::DecryptEncoded(CipherContext&) const+0x7c
TRACE: Stack frame 3: BackupStoreFilenameClear::MakeClearAvailable() const+0x1d0
TRACE: Stack frame 4: BackupStoreFilenameClear::GetClearFilename() const+0x12
TRACE: Stack frame 5: BackupClientDirectoryRecord::DecryptFilename(BackupStoreFilenameClear, long long, std::string const&)+0x2c
TRACE: Stack frame 6: BackupClientDirectoryRecord::DecryptFilename(BackupStoreDirectory::Entry*, std::string const&)+0x67
TRACE: Stack frame 7: BackupClientDirectoryRecord::UpdateItems(BackupClientDirectoryRecord::SyncParams&, std::string const&, std::string const&, Location
const&, BackupStoreDirectory*, std::vector<BackupStoreDirectory::Entry*, std::allocator<BackupStoreDirectory::Entry*> >&, std::vector<std::string, std::al
locator<std::string> >&, std::vector<std::string, std::allocator<std::string> > const&)+0xc3
TRACE: Stack frame 8: BackupClientDirectoryRecord::SyncDirectory(BackupClientDirectoryRecord::SyncParams&, long long, std::string const&, std::string con
st&, Location const&, bool)+0x1933
TRACE: Stack frame 9: BackupClientDirectoryRecord::UpdateItems(BackupClientDirectoryRecord::SyncParams&, std::string const&, std::string const&, Location
const&, BackupStoreDirectory*, std::vector<BackupStoreDirectory::Entry*, std::allocator<BackupStoreDirectory::Entry*> >&, std::vector<std::string, std::al
locator<std::string> >&, std::vector<std::string, std::allocator<std::string> > const&)+0x2077
WARNING: Exception thrown: CipherException(EVPFinalFailure) at CipherContext.cpp(467)
ERROR: TransformBlock failed on rEncoded: (size: 10) HEAD: 2a 0| BODY: ed 44 f6 5d db 84 2d cc
ERROR: TransformBlock lastEncoded: (size: 10) HEAD: 2a 0| BODY: 68 ee 47 6a fb 11 9f cb
ERROR: TransformBlock lastDecoded '1945.'
ERROR: Failed to decrypt filename for object 0x3f33 in directory 0x3438 (/local-a7/cyrus-spool/mail/domain/[REDACTED])
ERROR: SSL error while reading: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
ERROR: SSL error while reading: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
More information about the Boxbackup
mailing list