
Show HN: Encrypted Cloud file backup - frankhissen
http://www.frankhissen.de/crococrypt-en-frank-hissen-it-software.html
======
TheDong
I've been looking for a good truecrypt replacement, but this unfortunately
isn't it (yet at least).

1) Closed source. I can't take security software seriously without the source
code.

2) Windows only. Ditto for the above

3) There's no point in encrypting a folder with N files to result in N
encrypted files. It's _always_ more cryptographically sane to create a large
block of data (as truecrypt did) rather than reveal information about how many
inputs there were and allow people to correlate them.

Those three issues mean I won't be using this ( _especially_ the open source
bit).

~~~
mcdoug
Exactly what I was going to say with 1 & 2\. Your point #3 is arguable. It's
more secure to encrypt a block than files, but it's not always nearly as
convenient. You wouldn't want to sync a multi GB block to S3 every time it
changes. You have to encrypt filenames, and pad the files, but file-level
encryption has its uses.

~~~
ryan-c
Knowing the approximate file sizes and number of files in a directory,
especially with further context of overall directory structure can allow
someone to guess what the content is with high probability if the files are
"well known". Consider a directory containing pirated episodes of a tv show,
organized with a subdirectory per season. "Scene releases" tend to have one a
few possible approximate file sizes, and depending on how much padding, it may
be enough information to identify a set of files as all being scene releases
of the same show. Many other examples like this - anything "popular" that's
will have a fingerprint of extracted file sizes.

~~~
EmanueleAina
You can also encrypt N files yielding M > N blocks, to avoid much of the
issues you described while still avoiding the one-large-blob concern.

~~~
ryan-c
M - N must be "large enough" and must be unpredictable, though. It might need
to be pretty big.

------
sarciszewski
Where's the source code? Creating a closed-source cryptosystem is generally a
bad idea.

[https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle)

> You may not distribute or redistribute this software without permission.

This is a turn-off. MIT/BSD/GPL/WTFPL licensing is more likely to gain rapport
with hackers than non-free software.

> The keyfile is secured by a password using PKCS #5 (PBKDF2) with a
> SHA512/Whirlpool based HMAC using 100000 iterations and also AES and
> Twofish.

This sentence makes me greatly question the implementation of this system and
now I _really_ want to see the source code before I even think of trusting it
for any reason. PBKDF2 is generally performed with ONE hash function and
doesn't require block ciphers at all.

~~~
nadams
The whois is quite interesting as well:
[http://whois.domaintools.com/frankhissen.de](http://whois.domaintools.com/frankhissen.de)

If I'm reading that right - it says that 1&1 are the owners of the domain.

Yikes - and it looks like he is distributing a version of Java with it.

~~~
wongarsu
>If I'm reading that right - it says that 1&1 are the owners of the domain.

German domains should be looked up directly at denic.de for best results.
Owner and admin-c of the domain is Frank Hißen. 1&1 is tech-c and zone-c, but
not owner.

------
xenophonf
Regarding PBKDF2, you should read Colin Percival's paper on scrypt
([https://www.tarsnap.com/scrypt/scrypt.pdf](https://www.tarsnap.com/scrypt/scrypt.pdf)).

~~~
sarciszewski
Also, [https://password-hashing.net/candidates.html](https://password-
hashing.net/candidates.html) :)

------
LeoNatan25
"Encrypted Butt file backup"

Hmm...

Oh, right, [https://chrome.google.com/webstore/detail/cloud-to-butt-
plus...](https://chrome.google.com/webstore/detail/cloud-to-butt-
plus/apmlngnhgbnjpajelfkmabhkfapgnoai?hl=en) :-)

