head 1.1;
branch 1.1.1;
access;
symbols
pkgsrc-2025Q2:1.1.1.1.0.104
pkgsrc-2025Q2-base:1.1.1.1
pkgsrc-2025Q1:1.1.1.1.0.102
pkgsrc-2025Q1-base:1.1.1.1
pkgsrc-2024Q4:1.1.1.1.0.100
pkgsrc-2024Q4-base:1.1.1.1
pkgsrc-2024Q3:1.1.1.1.0.98
pkgsrc-2024Q3-base:1.1.1.1
pkgsrc-2024Q2:1.1.1.1.0.96
pkgsrc-2024Q2-base:1.1.1.1
pkgsrc-2024Q1:1.1.1.1.0.94
pkgsrc-2024Q1-base:1.1.1.1
pkgsrc-2023Q4:1.1.1.1.0.92
pkgsrc-2023Q4-base:1.1.1.1
pkgsrc-2023Q3:1.1.1.1.0.90
pkgsrc-2023Q3-base:1.1.1.1
pkgsrc-2023Q2:1.1.1.1.0.88
pkgsrc-2023Q2-base:1.1.1.1
pkgsrc-2023Q1:1.1.1.1.0.86
pkgsrc-2023Q1-base:1.1.1.1
pkgsrc-2022Q4:1.1.1.1.0.84
pkgsrc-2022Q4-base:1.1.1.1
pkgsrc-2022Q3:1.1.1.1.0.82
pkgsrc-2022Q3-base:1.1.1.1
pkgsrc-2022Q2:1.1.1.1.0.80
pkgsrc-2022Q2-base:1.1.1.1
pkgsrc-2022Q1:1.1.1.1.0.78
pkgsrc-2022Q1-base:1.1.1.1
pkgsrc-2021Q4:1.1.1.1.0.76
pkgsrc-2021Q4-base:1.1.1.1
pkgsrc-2021Q3:1.1.1.1.0.74
pkgsrc-2021Q3-base:1.1.1.1
pkgsrc-2021Q2:1.1.1.1.0.72
pkgsrc-2021Q2-base:1.1.1.1
pkgsrc-2021Q1:1.1.1.1.0.70
pkgsrc-2021Q1-base:1.1.1.1
pkgsrc-2020Q4:1.1.1.1.0.68
pkgsrc-2020Q4-base:1.1.1.1
pkgsrc-2020Q3:1.1.1.1.0.66
pkgsrc-2020Q3-base:1.1.1.1
pkgsrc-2020Q2:1.1.1.1.0.62
pkgsrc-2020Q2-base:1.1.1.1
pkgsrc-2020Q1:1.1.1.1.0.42
pkgsrc-2020Q1-base:1.1.1.1
pkgsrc-2019Q4:1.1.1.1.0.64
pkgsrc-2019Q4-base:1.1.1.1
pkgsrc-2019Q3:1.1.1.1.0.60
pkgsrc-2019Q3-base:1.1.1.1
pkgsrc-2019Q2:1.1.1.1.0.58
pkgsrc-2019Q2-base:1.1.1.1
pkgsrc-2019Q1:1.1.1.1.0.56
pkgsrc-2019Q1-base:1.1.1.1
pkgsrc-2018Q4:1.1.1.1.0.54
pkgsrc-2018Q4-base:1.1.1.1
pkgsrc-2018Q3:1.1.1.1.0.52
pkgsrc-2018Q3-base:1.1.1.1
pkgsrc-2018Q2:1.1.1.1.0.50
pkgsrc-2018Q2-base:1.1.1.1
pkgsrc-2018Q1:1.1.1.1.0.48
pkgsrc-2018Q1-base:1.1.1.1
pkgsrc-2017Q4:1.1.1.1.0.46
pkgsrc-2017Q4-base:1.1.1.1
pkgsrc-2017Q3:1.1.1.1.0.44
pkgsrc-2017Q3-base:1.1.1.1
pkgsrc-2017Q2:1.1.1.1.0.40
pkgsrc-2017Q2-base:1.1.1.1
pkgsrc-2017Q1:1.1.1.1.0.38
pkgsrc-2017Q1-base:1.1.1.1
pkgsrc-2016Q4:1.1.1.1.0.36
pkgsrc-2016Q4-base:1.1.1.1
pkgsrc-2016Q3:1.1.1.1.0.34
pkgsrc-2016Q3-base:1.1.1.1
pkgsrc-2016Q2:1.1.1.1.0.32
pkgsrc-2016Q2-base:1.1.1.1
pkgsrc-2016Q1:1.1.1.1.0.30
pkgsrc-2016Q1-base:1.1.1.1
pkgsrc-2015Q4:1.1.1.1.0.28
pkgsrc-2015Q4-base:1.1.1.1
pkgsrc-2015Q3:1.1.1.1.0.26
pkgsrc-2015Q3-base:1.1.1.1
pkgsrc-2015Q2:1.1.1.1.0.24
pkgsrc-2015Q2-base:1.1.1.1
pkgsrc-2015Q1:1.1.1.1.0.22
pkgsrc-2015Q1-base:1.1.1.1
pkgsrc-2014Q4:1.1.1.1.0.20
pkgsrc-2014Q4-base:1.1.1.1
pkgsrc-2014Q3:1.1.1.1.0.18
pkgsrc-2014Q3-base:1.1.1.1
pkgsrc-2014Q2:1.1.1.1.0.16
pkgsrc-2014Q2-base:1.1.1.1
pkgsrc-2014Q1:1.1.1.1.0.14
pkgsrc-2014Q1-base:1.1.1.1
pkgsrc-2013Q4:1.1.1.1.0.12
pkgsrc-2013Q4-base:1.1.1.1
pkgsrc-2013Q3:1.1.1.1.0.10
pkgsrc-2013Q3-base:1.1.1.1
pkgsrc-2013Q2:1.1.1.1.0.8
pkgsrc-2013Q2-base:1.1.1.1
pkgsrc-2013Q1:1.1.1.1.0.6
pkgsrc-2013Q1-base:1.1.1.1
pkgsrc-2012Q4:1.1.1.1.0.4
pkgsrc-2012Q4-base:1.1.1.1
pkgsrc-2012Q3:1.1.1.1.0.2
pkgsrc-2012Q3-base:1.1.1.1
pkgsrc-base:1.1.1.1
TNF:1.1.1;
locks; strict;
comment @# @;
1.1
date 2012.08.11.17.43.47; author agc; state Exp;
branches
1.1.1.1;
next ;
1.1.1.1
date 2012.08.11.17.43.47; author agc; state Exp;
branches;
next ;
desc
@@
1.1
log
@Initial revision
@
text
@
dhbitty is a small public key encryption
program written in C. It uses elliptic curve Diffie-Hellman in the form of
Curve25519 to establish a shared secret between two users, and uses that secret
to symmetrically encrypt and authenticate messages.
dhbitty differs from most other public key
encryption programs in a few significant ways.
- There are no private key files; only passphrases. Never lose that pesky
thing again.
- Both the sender and the receiver can decrypt a message. In fact, there is
no distinction between sender and receiver. Both passphrases must be strong.
- There is no signing. A similarly useful form of authentication occurs using
only DH.
dhbitty attempts to be as simple as possible. It is
not optimized, but achieves a comfortable speed for most uses. It does not use
floating point numbers, or integers longer than 32 bits. It does not contain
more algorithms than are needed.
Download: dhbitty.c
My dhbitty.c and this page are in the public
domain.
Example
This is how Alice generates her public key with dhbitty:
$ dhbitty generate alice_public_key.txt
username:passphrase (this is visible!): alice:Keyfiles be damned!
Done.
Bob will do the same thing:
$ dhbitty generate bob_public_key.txt
username:passphrase (this is visible!): bob:Bob's Spectacular Passphrase
Done.
Alice will publish her alice_public_key.txt, and Bob
will publish his bob_public_key.txt. They can now
access each other's public keys. (But they should be careful that Eve cannot
surreptitiously replace either public key with her own!)
Alice wants to send files to Bob. She packages them into a
.tar archive (or any other type of archive with
timestamps), along with her message. Then she uses dhbitty:
$ dhbitty encrypt bob_public_key.txt files_to_bob.tar files_to_bob.tar.dhbt
username:passphrase (this is visible!): alice:Keyfiles be damned!
Done.
Alice sends files_to_bob.tar.dhbt to Bob. Bob will
use dhbitty to decrypt this archive:
$ dhbitty decrypt files_to_bob.tar.dhbt files_to_bob.tar
username:passphrase (this is visible!): bob:Bob's Spectacular Passphrase
This is the public key of file's secondary owner:
0002f02b318c307bac07f3148a33c975cea04b79a870f0a5c7771cd38cc1986e
Done.
Bob can verify that the public key dhbitty just gave him indeed is Alice's
public key. He unpacks the now-decrypted archive to access the files Alice sent
to him.
In practice, Alice and Bob should use a system like diceware to pick
passphrases, in order to be confident of their strength. Seven words picked
using diceware is a good choice.
Technical summary
The key derivation function works like this: T(H(H(input) || S(H(input)))).
Here H is a 512-bit hash function built by using the EnRUPT block cipher in the
sponge construction. S is an expensive function that compresses 512 bits to 32
bits. Finally, T truncates 512 bits to 256 bits. The AT cost of this
construction is similar to 232 iterations of SHA-1; I'll reserve the
details for another document. The return value works directly as a Curve25519
private key (after fixing several bits, which is handled within the DH
function).
When a file is encrypted, both public keys will be included in the output
file, in sorted order.
For symmetric encryption and authentication, an EnRUPT sponge context is
initialized for each using the shared secret, a random 128-bit nonce, and a
public string ("encrypt" or "authenticate"). The data is encrypted and then
authenticated in a single pass.
If on Windows, CryptGenRandom is used for randomness. Otherwise, reading
from /dev/urandom is attempted.
This is the file format:
- 32 bytes: public key 1
- 32 bytes: public key 2
- 16 bytes: nonce
- ?? bytes: ciphertext
- 16 bytes: tag
Cipherdev
@
1.1.1.1
log
@Import dhbitty-20120812 into the Packages Collection.
dhbitty is a small public key encryption program written in C. It
uses elliptic curve Diffie-Hellman in the form of Curve25519 to
establish a shared secret between two users, and uses that secret to
symmetrically encrypt and authenticate messages.
There are no private key files; only passphrases. Never lose that
pesky thing again.
Both the sender and the receiver can decrypt a message. In fact,
there is no distinction between sender and receiver. Both passphrases
must be strong.
There is no signing. A similarly useful form of authentication occurs
using only DH. dhbitty attempts to be as simple as possible. It is
not optimized, but achieves a comfortable speed for most uses. It
does not use floating point numbers, or integers longer than 32 bits.
It does not contain more algorithms than are needed.
Example
This is how Alice generates her public key with dhbitty:
$ dhbitty generate alice_public_key.txt
username:passphrase (this is visible!): alice:Keyfiles be damned!
Done.
Bob will do the same thing:
$ dhbitty generate bob_public_key.txt
username:passphrase (this is visible!): bob:Bob's Spectacular Passphrase
Done.
Alice will publish her alice_public_key.txt, and Bob will publish his bob_public_key.txt. They can now access each other's
public keys. (But they should be careful that Eve cannot surreptitiously replace either public key with her own!)
Alice wants to send files to Bob. She packages them into a .tar archive (or any other type of archive with timestamps), along
with her message. Then she uses dhbitty:
$ dhbitty encrypt bob_public_key.txt files_to_bob.tar files_to_bob.tar.dhbt
username:passphrase (this is visible!): alice:Keyfiles be damned!
Done.
Alice sends files_to_bob.tar.dhbt to Bob. Bob will use dhbitty to decrypt this archive:
$ dhbitty decrypt files_to_bob.tar.dhbt files_to_bob.tar
username:passphrase (this is visible!): bob:Bob's Spectacular Passphrase
This is the public key of file's secondary owner:
0002f02b318c307bac07f3148a33c975cea04b79a870f0a5c7771cd38cc1986e
Done.
Bob can verify that the public key dhbitty just gave him indeed is Alice's public key. He unpacks the now-decrypted archive to
access the files Alice sent to him.
In practice, Alice and Bob should use a system like diceware to pick passphrases, in order to be confident of their strength.
Seven words picked using diceware is a good choice.
@
text
@@