Sectar uses Rijndael which is a symmetic cypher. (the same
key is used for encryption and decryption)
I guess you mean asymmetic encryption? But that would also
require to use the private key for decryption. If you lose
your private key, you are also toast. Besides, symmetric
en/decryption is about 100 to 500 times faster than pure
asymmetic en/decryption.
BC547
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No. I mean symmetric encryption as gpg refers to this term.
Asymmetric is public/private key.
Symmetric is private key only.
You can memorize your private key to protect it from disk
crashes.
sectar should NOT be encouraging the generation of
catch-22's. this is actually a well known and often warned
about issue with asymmetric encruption on backups.
asymmetric encryption is good for transient data and
non-archival (eg https), but very poor for archival storage
because its harder to save the passkeys against loss.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not familiar how gpg refers to the term symmetric
encryption :-) Do you perhaps mean the hybrid encryption
form where bulk data is encrypted with a symmetric key, and
the used symmetric key is encrypted with an asymmetric key
which is protected with a pass phrase?
Memorize private key? A private key is always totally
random (both for symmetric as asymmetric systems). It's
however perfectly possible to derive a symmetric key based
on a passphrase (e.g. hashing the passphrase). But a
passphrase with an entropy of 256 bit would be a very long
passphrase (80 characters or more).
I'm again unfamiliar with the term 'catch-22s' :-) But I
totally agree on the uses for asymmetric encryption you
mention.
kind regard,
BC547 aka Dirk Janssens
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I mean symmetric encryption where KEYS ARE NEVER STORED
ON ANY MEDIA.
I mean the situation where bulk data is stored with
symmetric encryption key, but this key is never ever stored
on disk or tape or anything at all. It's generated from the
passphrase when the user types it.
catch-22 refers to chicken-and-egg situation, e.g.:
"I blew up my entire machine and need to restore the
encrypted backup, but the encryption key files are stored on
the encrypted backup".
This is the catch-22 situation that sectar creates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(I would call it rather: "Create cryptographic keys based
solely on a passphrase" since the term "symmetric
encryption" has nothing to do with the way the random key
is generated :-)
However, if you want the same securitylevel as a truly
random generated key, the pass phrase must be 80 or more
bytes in length (perhaps even over 100 characters).
What you mean, is not difficult to add. It could be as
simple as asking a user for input and create a hash of this
input. I already was thinking of implementing this myself
in sectar when I have some time. (It wouldn't even be
nessecary to modify the sectar code if you don't want that.
A simple perl script could do this already.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=250930
Sectar uses Rijndael which is a symmetic cypher. (the same
key is used for encryption and decryption)
I guess you mean asymmetic encryption? But that would also
require to use the private key for decryption. If you lose
your private key, you are also toast. Besides, symmetric
en/decryption is about 100 to 500 times faster than pure
asymmetic en/decryption.
BC547
Logged In: YES
user_id=106082
No. I mean symmetric encryption as gpg refers to this term.
Asymmetric is public/private key.
Symmetric is private key only.
You can memorize your private key to protect it from disk
crashes.
sectar should NOT be encouraging the generation of
catch-22's. this is actually a well known and often warned
about issue with asymmetric encruption on backups.
asymmetric encryption is good for transient data and
non-archival (eg https), but very poor for archival storage
because its harder to save the passkeys against loss.
Logged In: YES
user_id=250930
I'm not familiar how gpg refers to the term symmetric
encryption :-) Do you perhaps mean the hybrid encryption
form where bulk data is encrypted with a symmetric key, and
the used symmetric key is encrypted with an asymmetric key
which is protected with a pass phrase?
Memorize private key? A private key is always totally
random (both for symmetric as asymmetric systems). It's
however perfectly possible to derive a symmetric key based
on a passphrase (e.g. hashing the passphrase). But a
passphrase with an entropy of 256 bit would be a very long
passphrase (80 characters or more).
I'm again unfamiliar with the term 'catch-22s' :-) But I
totally agree on the uses for asymmetric encryption you
mention.
kind regard,
BC547 aka Dirk Janssens
Logged In: YES
user_id=106082
No, I mean symmetric encryption where KEYS ARE NEVER STORED
ON ANY MEDIA.
I mean the situation where bulk data is stored with
symmetric encryption key, but this key is never ever stored
on disk or tape or anything at all. It's generated from the
passphrase when the user types it.
catch-22 refers to chicken-and-egg situation, e.g.:
"I blew up my entire machine and need to restore the
encrypted backup, but the encryption key files are stored on
the encrypted backup".
This is the catch-22 situation that sectar creates.
Logged In: YES
user_id=250930
ok.. now I understand :-)
(I would call it rather: "Create cryptographic keys based
solely on a passphrase" since the term "symmetric
encryption" has nothing to do with the way the random key
is generated :-)
However, if you want the same securitylevel as a truly
random generated key, the pass phrase must be 80 or more
bytes in length (perhaps even over 100 characters).
What you mean, is not difficult to add. It could be as
simple as asking a user for input and create a hash of this
input. I already was thinking of implementing this myself
in sectar when I have some time. (It wouldn't even be
nessecary to modify the sectar code if you don't want that.
A simple perl script could do this already.)