Skip to content
GitLab
Menu
Projects
Groups
Snippets
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Menu
Open sidebar
Marcus Hoffmann
nettle
Commits
74ac6734
Commit
74ac6734
authored
Feb 27, 2002
by
Niels Möller
Browse files
Fixed hyphenated words.
Rev: src/nettle/nettle.texinfo:1.15
parent
7a70cc7a
Changes
1
Hide whitespace changes
Inline
Side-by-side
nettle.texinfo
View file @
74ac6734
...
...
@@ -97,7 +97,7 @@ translation approved by the Free Software Foundation.
@top Nettle
This document describes the nettle low-level cryptographic library. You
can use the library directly from your C
-
programs, or (recommended)
can use the library directly from your C
programs, or (recommended)
write or use an object-oriented wrapper for your favorite language or
application.
...
...
@@ -139,7 +139,7 @@ In particular, Nettle doesn't do algorithm selection. It doesn't do
memory allocation. It doesn't do any I/O.
The idea is that one can build several application and context specific
interfaces on top of Nettle, and share the code, test
-
cases, benchmarks,
interfaces on top of Nettle, and share the code, test
cases, benchmarks,
documentation, etc. For this first version, the only application using
Nettle is LSH, and it uses an object-oriented abstraction on top of the
library.
...
...
@@ -489,7 +489,7 @@ These are all the hash functions that Nettle implements.
A @dfn
{
cipher
}
is a function that takes a message or @dfn
{
plaintext
}
and a secret @dfn
{
key
}
and transforms it to a @dfn
{
ciphertext
}
. Given
only the ciphertext, but not the key, it should be hard to find the
clear-
text. Given matching pairs of plaintext and ciphertext, it should
plain
text. Given matching pairs of plaintext and ciphertext, it should
be hard to find the key.
There are two main classes of ciphers: Block ciphers and stream ciphers.
...
...
@@ -519,7 +519,7 @@ same as for a One Time Pad: @emph{never} ever use the same key twice.
A common misconception is that encryption, by itself, implies
authentication. Say that you and a friend share a secret key, and you
receive an encrypted message. You apply the key, and get a
clear-
text
receive an encrypted message. You apply the key, and get a
plain
text
message that makes sense to you. Can you then be sure that it really was
your friend that wrote the message you're reading? The answer is no. For
example, if you were using a block cipher in ECB mode, an attacker may
...
...
@@ -977,17 +977,17 @@ ones without weak keys or other oddity.
@comment node-name, next, previous, up
@section Cipher Block Chaining
When using @acronym
{
CBC
}
mode,
clear-
text blocks are not encrypted
When using @acronym
{
CBC
}
mode,
plain
text blocks are not encrypted
independently of each other, like in Electronic Cook Book mode. Instead,
when encrypting a block in @acronym
{
CBC
}
mode, the previous ciphertext
block is XOR:ed with the
clear-
text before it is fed to the block cipher.
block is XOR:ed with the
plain
text before it is fed to the block cipher.
When encrypting the first block, a random block called an @dfn
{
IV
}
, or
Initialization Vector, is used as the ``previous ciphertext block''. The
IV should be chosen randomly, but it need not be kept secret, and can
even be transmitted in the clear together with the encrypted data.
In symbols, if @code
{
E
_
k
}
is the encryption function of a block
-
cipher,
and @code
{
IV
}
is the initialization vector, then @code
{
n
}
clear-
text blocks
In symbols, if @code
{
E
_
k
}
is the encryption function of a block
cipher,
and @code
{
IV
}
is the initialization vector, then @code
{
n
}
plain
text blocks
@code
{
M
_
1
}
,@dots
{}
@code
{
M
_
n
}
are transformed into @code
{
n
}
ciphertext blocks
@code
{
C
_
1
}
,@dots
{}
@code
{
C
_
n
}
as follows:
...
...
@@ -1102,7 +1102,7 @@ such constructions have weaknesses. A better construction is
For an underlying hash function @code
{
H
}
, with digest size @code
{
l
}
and
internal block size @code
{
b
}
, @acronym
{
HMAC-H
}
is constructed as
follows: From a given key @code
{
k
}
, two distinct sub
-
keys @code
{
k
_
i
}
and
follows: From a given key @code
{
k
}
, two distinct subkeys @code
{
k
_
i
}
and
@code
{
k
_
o
}
are constructed, both of length @code
{
b
}
. The
@acronym
{
HMAC-H
}
of a message @code
{
m
}
is then computed as @code
{
H(k
_
o |
H(k
_
i | m))
}
, where @code
{
|
}
denotes string concatenation.
...
...
@@ -1123,7 +1123,7 @@ functions:
@deftypefun void hmac
_
set
_
key (void *@var
{
outer
}
, void *@var
{
inner
}
, void *@var
{
state
}
, const struct nettle
_
hash *@var
{
H
}
, unsigned @var
{
length
}
, const uint8
_
t *@var
{
key
}
)
Initializes the three context structs from the key. The @var
{
outer
}
and
@var
{
inner
}
contexts corresponds to the sub
-
keys @code
{
k
_
o
}
and
@var
{
inner
}
contexts corresponds to the subkeys @code
{
k
_
o
}
and
@code
{
k
_
i
}
. @var
{
state
}
is used for hashing the message, and is
initialized as a copy of the @var
{
inner
}
context.
@end deftypefun
...
...
@@ -1709,12 +1709,12 @@ Yarrow-256, which is similar, but uses @acronym{SHA256} and
Yarrow was an almost finished project, the paper mentioned above is the
closest thing to a specification for it, but some smaller details are
left out. There is no official reference implementation or test cases.
This section includes an overview of Yarrow, but the details of
This section includes an overview of Yarrow, but
for
the details of
Yarrow-256, as implemented by Nettle, you have to consult the source
code. Maybe a complete specification can be written later.
Yarrow can use many sources (at least two are needed for proper
reseeding), and two randomness "pools", referred to the "slow pool" and
reseeding), and two randomness "pools", referred to
as
the "slow pool" and
the "fast pool". Input from the sources is fed alternatingly into the
two pools. When one of the sources has contributed 100 bits of entropy
to the fast pool, a "fast reseed" happens and the fast pool is mixed
...
...
@@ -1810,7 +1810,7 @@ Initializes the context.
@end deftypefun
@deftypefun unsigned yarrow
_
key
_
event
_
estimate(struct yarrow
_
key
_
event
_
ctx *@var
{
ctx
}
, unsigned @var
{
key
}
, unsigned @var
{
time
}
)
@var
{
key
}
is the id of the key (ASCII value, hardware key
-
code, X
@var
{
key
}
is the id of the key (ASCII value, hardware key
code, X
keysym, @dots
{}
it doesn't matter), and @var
{
time
}
is the timestamp of
the event. The time must be given in units matching the resolution by
which you read the clock. If you read the clock with microsecond
...
...
@@ -1865,7 +1865,7 @@ variable @code{des_check_key}, and the functions @code{des_cbc_cksum}
@node Nettle soup, Installation, Reference, Top
@comment node-name, next, previous, up
@chapter Traditional Nettle Soup
For the serious nettle hacker, here is a recipe for nettle
-
soup. 4 servings
For the serious nettle hacker, here is a recipe for nettle
soup. 4 servings
@itemize @w
{}
@item
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment