| /external/llvm/lib/CodeGen/ |
| LiveRangeCalc.cpp | 152 // VNInfo SSA form. Perform a search for all predecessor blocks where we
163 // live-out and live-in blocks. The unique value optimization is not
244 // Both updateSSA() and LiveRangeUpdater benefit from ordered blocks, but
|
| StackColoring.cpp | 109 /// Maps serial numbers to basic blocks.
111 /// Maps basic blocks to a serial number.
163 /// in and out blocks.
301 // is a map from blocks to bitvectors where the bitvectors represent which
404 // Create the interval for the basic blocks with lifetime markers in them.
431 // Create the interval of the blocks that we previously found to be 'alive'.
|
| /external/mesa3d/src/gallium/auxiliary/gallivm/ |
| lp_bld_format_yuv.c | 51 * @param packed is a <n x i32> vector with the packed UYVY blocks
119 * @param packed is a <n x i32> vector with the packed YUYV blocks
440 * @param packed is a <n x i32> vector with the packed YUYV blocks
|
| /external/openssh/ |
| PROTOCOL | 260 uint64 f_blocks /* number of blocks (unit f_frsize) */
261 uint64 f_bfree /* free blocks in file system */
262 uint64 f_bavail /* free blocks for non-root */
|
| /external/qemu/distrib/jpeg-6b/ |
| jdinput.c | 85 /* Size in DCT blocks */
175 /* Sampling factors give # of blocks of component in each MCU */
180 /* Figure number of non-dummy blocks in last MCU column & row */
|
| /external/srtp/doc/ |
| draft-irtf-cfrg-icm-00.txt | 126
Crypto Forum Research Group David A. McGrew
Internet Draft Cisco Systems, Inc.
Expires April, 2003 October, 2002
Integer Counter Mode
<draft-irtf-cfrg-icm-00.txt>
Status of this Memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC-2026. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document specifies Integer Counter Mode (ICM), a mode of
operation of a block cipher which defines an indexed keystream
generator (which generates a keystream segment given an index).
This mode is efficient, parallelizable, and has been proven secure
given realistic assumptions about the block cipher. Test vectors
are provided for AES.
Counter Mode admits many variations. The variant specified in
this document is secure and flexible, yet it enables a single
implementation of a keystream generator to suffice in different
application domains.
McGrew [Page 1]
Internet Draft Integer Counter Mode October, 2002
2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [B97].
3. Introduction
Counter Mode is a way to define a pseudorandom keystream generator
using a block cipher [CTR]. The keystream can be used for additive
encryption, key derivation, or any other application requiring
pseudorandom data.
In ICM, the keystream is logically broken into segments. Each
segment is identified with a segment index, and the segments have
equal lengths. This segmentation makes ICM especially appropriate
for securing packet-based protocols.
4. ICM
In this section, ICM keystream generation and encryption are
defined.
4.1. ICM Parameters
The following parameters are used in ICM. These parameters MUST
remain fixed for any given use of a key.
Parameter Meaning
-----------------------------------------------------------------
BLOCK_LENGTH the number of octets in the cipher block
KEY_LENGTH the number of octets in the cipher key
OFFSET_LENGTH the number of octets in the offset
SEGMENT_INDEX_LENGTH the number of octets in the segment index
BLOCK_INDEX_LENGTH the number of octets in the block index
4.2. Keystream Segments
Conceptually, ICM is a keystream generator that takes a secret key
and a segment index as an input and then outputs a keystream
segment. The segmentation lends itself to packet encryption, as
each keystream segment can be used to encrypt a distinct packet.
A counter is a value containing BLOCK_LENGTH octets which is
McGrew [Page 2]
Internet Draft Integer Counter Mode October, 2002
incremented using an increment function based on integer addition,
to produce a sequence of distinct values which are used as inputs to
the block cipher. (In the context of this specification, an integer
is an octet string, the most significant of which is the first.)
The output blocks of the cipher are concatenated to form the
keystream segment. The first octet of the segment is the first
octet of the first output block, and so on. A schematic of this
process is shown in Figure 1.
Figure 1. The generation of a keystream segment given a segment
index and a block cipher key K. Here C[i] and S[i] denote the ith
counter and keystream block, respectively.
segment
index
|
v
C[0] -----> C[1] -----> C[2] -----> ...
| | |
v v v
+---+ +---+ +---+
K->| E | K->| E | K->| E | ...
+---+ +---+ +---+
| | |
v v v
S[0] S[1] S[2] ...
The ith counter C[i] of the keystream segment with segment index s
is defined as
C[i] = (i + s * (256^BLOCK_INDEX_LENGTH)) (+) r
where r denotes the shifted Offset, which is defined as the Offset
times 256^(BLOCK_LENGTH - OFFSET_LENGTH). (This multiplication
left-shifts the Offset so that it is aligned with the leftmost
edge of the block.) Here ^ denotes exponentiation and (+) denotes
the bitwise exclusive-or operation.
The number of blocks in any segment MUST NOT exceed
256^BLOCK_INDEX_LENGTH. The number of segments MUST NOT exceed
256^SEGMENT_INDEX_LENGTH. These restrictions ensure the uniqueness
of each block cipher input. They also imply that each segment
contains no more than (256^BLOCK_INDEX_LENGTH)*BLOCK_LENGTH octets.
The sum of SEGMENT_INDEX_LENGTH and BLOCK_INDEX_LENGTH MUST NOT
exceed BLOCK_LENGTH / 2. This requirement protects the ICM
keystream generator from potentially failing to be pseudorandom (see
McGrew [Page 3]
Internet Draft Integer Counter Mode October, 2002
the rationale).
Figure 2. An illustration of the structure of a counter with
BLOCK_LENGTH = 8, SEGMENT_INDEX_LENGTH = 2, and BLOCK_INDEX_LENGTH
= 2. The field marked `null' is not part of either the block
or segment indices.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| null |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| segment index | block index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. ICM Encryption
Unless otherwise specified, ICM encryption consists of bitwise
exclusive-oring the keystream into the plaintext to produce
the ciphertext.
4.4 ICM KEY
An ICM key consists of the block cipher key and an Offset. The
Offset is an integer with OFFSET_LENGTH octets, which is used to
`randomize' the logical starting point of keystream. The Offset is
crucial to providing security; see the rationale. The value of
OFFSET_LENGTH SHOULD be at least half that of BLOCK_LENGTH.
For the purposes of transporting an ICM key, e.g. in a signaling
protocol, that key SHOULD be considered a sequence of octets in
which the block cipher key precedes the Offset.
5. Implementation Considerations
Implementation of the `add one modulo 2^m' operation is simple. For
example, with BLOCK_LENGTH = 8 (m=64), it can be implemented in C as
if (!++x) ++y;
where x and y are 32-bit unsigned integers in network byte order.
The implementation of general purpose addition modulo 2^m is
slightly more complicated.
The fact that the Offset is left-aligned enables an implementation
McGrew [Page 4]
Internet Draft Integer Counter Mode October, 2002
to avoid propagating carry values outside of the block index and/or
the segment index. Choosing an OFFSET_LENGTH value equal to half
that of BLOCK_LENGTH avoids all of these carries, since the Offset
is then shifted so that it occupies the most significant octets of
the block, while the block and segment indices occupy the least
significant ones.
6. Parameters and Test Vectors for AES
This section provides ICM parameters and test vectors for AES
with a 128 bit block size and 128 bit key (that is, with a
BLOCK_LENGTH and KEY_LENGTH of 16).
All integers are expressed in hexadecimal. Each consecutive pair of
hex digits corresponds to an octet, so that the integer
000102030405060708090A0B0C0D0E0F corresponds to the octet sequence
{ 00, 01, 02, 02 ... }.
BLOCK_LENGTH 16
KEY_LENGTH 16
OFFSET_LENGTH 14
SEGMENT_INDEX_LENGTH 6
BLOCK_INDEX_LENGTH 2
Block Cipher Key: 2b7e151628aed2a6abf7158809cf4f3c
Offset: f0f1f2f3f4f5f6f7f8f9fafbfcfd
Segment Index: 000000000000
Keystream: e03ead0935c95e80e166b16dd92b4eb4
d23513162b02d0f72a43a2fe4a5f97ab
...
The counter values that correspond to the keystream blocks are
outlined below.
Counter Keystream
f0f1f2f3f4f5f6f7f8f9fafbf (…)
|
| /external/valgrind/main/memcheck/ |
| mc_errors.c | 59 // Different kinds of blocks.
98 // This covers heap blocks (normal and from mempools) and user-defined
99 // blocks.
236 // Call to strcpy, memcpy, etc, with overlapping blocks.
482 "in %'u%s blocks"
497 emit( " <text>%'lu%s bytes in %'u%s blocks"
511 "%'lu%s (%'lu%s direct, %'lu%s indirect) bytes in %'u%s blocks"
522 "%'lu%s bytes in %'u%s blocks are %s in loss record %'u of %'u\n",
[all...] |
| /external/webp/src/dec/ |
| vp8i.h | 75 // and two 8x8 chroma blocks (u/v). These are better be 16-bytes aligned,
77 // top-left samples (from previously decoded blocks), along with four
266 // bit-wise info about the content of each sub-4x4 blocks: there are 16 bits
|
| /frameworks/base/docs/html/training/implementing-navigation/ |
| lateral.jd | 23 <li><a href="{@docRoot}design/building-blocks/tabs.html">Android Design: Tabs</a></li>
170 <a href="{@docRoot}design/building-blocks/tabs.html">tabs</a> offer users a familiar interface
274 <a href="{@docRoot}design/building-blocks/tabs.html#scrollable">scrollable tabs</a> for a shorter
|
| /libcore/luni/src/main/java/java/io/ |
| PipedInputStream.java | 194 * reached. If there is no data in the pipe, this method blocks until data
260 * byte array {@code bytes} starting at {@code byteOffset}. Blocks until at
366 * This method blocks as long as {@code buffer} is full.
|
| /libcore/luni/src/main/java/java/util/concurrent/ |
| BlockingQueue.java | 27 * blocks the current thread indefinitely until the operation can succeed,
28 * and the fourth blocks for only a given maximum time limit before giving
37 * <td ALIGN=CENTER><em>Blocks</em></td>
|
| /system/core/libsparse/ |
| output_file.c | 693 /* Write a contiguous region of data blocks from a memory buffer */
699 /* Write a contiguous region of data blocks with a fill value */
754 /* Write a contiguous region of data blocks from a file */
|
| /system/extras/ext4_utils/ |
| contents.c | 99 u32 blocks; local
107 blocks = DIV_ROUND_UP(dentry_size(entries, dentries), info.block_size);
108 len = blocks * info.block_size;
|
| /external/ceres-solver/internal/ceres/ |
| problem_test.cc | 162 "Duplicate parameter blocks");
166 "Duplicate parameter blocks");
255 // Creating parameter blocks multiple times is ignored.
372 // Make the dynamic problem tests (e.g. for removing residual blocks)
677 // parameter blocks to the residual blocks.
[all...] |
| solver_impl_test.cc | 297 // expect the order for residual blocks for each e_block to be
363 // expect the order for residual blocks for each e_block to be
436 // Verify that right parmeter block and the residual blocks have
699 // The parameters must be in separate blocks so that they can be individually
764 EXPECT_EQ(summary.error, "Problem contains no parameter blocks.");
775 EXPECT_EQ(summary.error, "Problem contains no residual blocks.");
[all...] |
| /external/libnfc-nci/src/nfc/include/ |
| rw_api.h | 220 UINT16 num_block; /* number of blocks if I93_INFO_FLAG_MEM_SIZE */
510 ** A sector is 256 contiguous blocks (1024 bytes).
676 ** blocks per read) attribute.
702 ** blocks per write) attribute.
[all...] |
| /external/markdown/MarkdownTest/Tests_2004/ |
| Markdown Documentation - Syntax.text | 22 * [Code Blocks](#precode)
171 However, inside Markdown code spans and blocks, angle brackets and
281 and code blocks:
457 <h3 id="precode">Code Blocks</h3>
459 Pre-formatted code blocks are used for writing about programming or
516 Regular Markdown syntax is not processed within code blocks. E.g.,
|
| /external/markdown/MarkdownTest/Tests_2007/ |
| Markdown Documentation - Syntax.text | 22 * [Code Blocks](#precode)
171 However, inside Markdown code spans and blocks, angle brackets and
281 and code blocks:
457 <h3 id="precode">Code Blocks</h3>
459 Pre-formatted code blocks are used for writing about programming or
516 Regular Markdown syntax is not processed within code blocks. E.g.,
|
| /external/markdown/tests/extensions-x-def_list/ |
| markdown-syntax.txt | 22 * [Code Blocks](#precode)
171 However, inside Markdown code spans and blocks, angle brackets and
281 and code blocks:
457 <h3 id="precode">Code Blocks</h3>
459 Pre-formatted code blocks are used for writing about programming or
516 Regular Markdown syntax is not processed within code blocks. E.g.,
|
| /external/markdown/tests/markdown-test/ |
| markdown-syntax.txt | 22 * [Code Blocks](#precode)
171 However, inside Markdown code spans and blocks, angle brackets and
281 and code blocks:
457 <h3 id="precode">Code Blocks</h3>
459 Pre-formatted code blocks are used for writing about programming or
516 Regular Markdown syntax is not processed within code blocks. E.g.,
|
| /external/proguard/src/proguard/optimize/evaluation/ |
| PartialEvaluator.java | 492 // Utility methods to evaluate instruction blocks.
567 // Execute all resulting instruction blocks on the execution stack.
570 if (DEBUG) System.out.println("Popping alternative branch out of "+instructionBlockStack.size()+" blocks");
588 * Instruction blocks that are to be evaluated as a result are pushed on
[all...] |
| /external/v8/src/ |
| handles.cc | 51 int n = impl->blocks()->length();
54 (isolate->handle_scope_data()->next - impl->blocks()->last()));
76 if (!impl->blocks()->is_empty()) {
77 Object** limit = &impl->blocks()->last()[kHandleBlockSize];
89 // Add the extension to the global list of blocks, but count the
91 impl->blocks()->Add(result);
[all...] |
| hydrogen.h | 224 const ZoneList<HBasicBlock*>* blocks() const { return &blocks_; } function in class:v8::internal::HLoopInformation
251 const ZoneList<HBasicBlock*>* blocks() const { return &blocks_; } function in class:v8::internal::HGraph
736 // pair of return blocks in the context. When not inlining, there is no
741 // return blocks. NULL in all other cases.
753 // A class encapsulating (lazily-allocated) break and continue blocks for
927 // from the loop. All blocks except loop_entry can be NULL. The return
[all...] |
| /prebuilts/gcc/linux-x86/host/i686-linux-glibc2.7-4.4.3/i686-linux/include/c++/4.4.3/ext/ |
| bitmap_allocator.h | 288 /** @brief The number of Blocks pointed to by the address pair
584 * blocks by adding this block to the free list or deleting this
585 * or larger blocks from the free list.
595 // which block to remove from the list of free blocks.
599 // last block in the list of free blocks. We just free
778 * is the number of blocks of size sizeof(value_type) within
|
| /prebuilts/ndk/5/sources/cxx-stl/gnu-libstdc++/include/ext/ |
| bitmap_allocator.h | 288 /** @brief The number of Blocks pointed to by the address pair
584 * blocks by adding this block to the free list or deleting this
585 * or larger blocks from the free list.
595 // which block to remove from the list of free blocks.
599 // last block in the list of free blocks. We just free
778 * is the number of blocks of size sizeof(value_type) within
|
