The Linde–Buzo–Gray algorithm (named after its creators Yoseph Linde, Andrés Buzo and Robert M. Gray, who designed it in 1980) is an iterative vector quantization algorithm to improve a small set of vectors (codebook) to represent a larger set of vectors (training set), such that it will be locally optimal. It combines Lloyd's Algorithm with a splitting technique in which larger codebooks are built from smaller codebooks by splitting each code vector in two. The core idea of the algorithm is that by splitting the codebook such that all code vectors from the previous codebook are present, the new codebook must be as good as the previous one or better. == Description == The Linde–Buzo–Gray algorithm may be implemented as follows: algorithm linde-buzo-gray is input: set of training vectors training, codebook to improve old-codebook output: codebook that is twice the size and better or as good as old-codebook new-codebook ← {} for each old-codevector in old-codebook do insert old-codevector into new-codebook insert old-codevector + 𝜖 into new-codebook where 𝜖 is a small vector return lloyd(new-codebook, training) algorithm lloyd is input: codebook to improve, set of training vectors training output: improved codebook do previous-codebook ← codebook clusters ← divide training into |codebook| clusters, where each cluster contains all vectors in training who are best represented by the corresponding vector in codebook for each cluster cluster in clusters do the corresponding code vector in codebook ← the centroid of all training vectors in cluster while difference in error representing training between codebook and previous-codebook > 𝜖 return codebook
Latent semantic mapping
Latent semantic mapping (LSM) is a data-driven framework to model globally meaningful relationships implicit in large volumes of (often textual) data. It is a generalization of latent semantic analysis. In information retrieval, LSA enables retrieval on the basis of conceptual content, instead of merely matching words between queries and documents. LSM was derived from earlier work on latent semantic analysis. There are 3 main characteristics of latent semantic analysis: Discrete entities, usually in the form of words and documents, are mapped onto continuous vectors, the mapping involves a form of global correlation pattern, and dimensionality reduction is an important aspect of the analysis process. These constitute generic properties, and have been identified as potentially useful in a variety of different contexts. This usefulness has encouraged great interest in LSM. The intended product of latent semantic mapping, is a data-driven framework for modeling relationships in large volumes of data. Mac OS X v10.5 and later includes a framework implementing latent semantic mapping.
HKDF
HKDF is a multi-purpose key derivation function (KDF) based on the HMAC message authentication code. HKDF follows "extract-then-expand" paradigm, where the KDF logically consists of two modules: the first stage takes the input keying material and "extracts" from it a fixed-length pseudorandom key, and then the second stage "expands" this key into several additional, independent pseudorandom keys as the output of the KDF. == Mechanism == HKDF is the composition of two functions, HKDF-Extract and HKDF-Expand: HKDF(salt, IKM, info, length) = HKDF-Expand(HKDF-Extract(salt, IKM), info, length) === HKDF-Extract === HKDF-Extract (XTR) takes "input key material" or "source key material" (IKM or SKM) such as a shared secret generated using Diffie-Hellman; an optional, non-secret, random or pseudorandom salt (r); and generates a cryptographic key called the PRK ("pseudorandom key"). HKDF-Extract acts as a "randomness extractor", specifically a "computational extractor", taking a potentially non-uniform value of sufficient min-entropy and generating a value indistinguishable from a uniform random value (pseudorandom). Computational extractors assume attackers are computationally bounded and source entropy may only exist in a computational sense. Such extractors can be built using cryptographic functions under suitable assumptions, modeled as universal hash function (in the generic case) or a random oracle (in constrained scenarios like sources with weak entropy). Salt (r) acts as a "source-independent extractor", strengthening HKDF's security guarantees. Using a fixed public r is safe for multiple invocations of HKDF (on "independent" but secret IKMs which may or may not be derived from the same source), provided r isn't chosen or manipulated by an attacker. Ideally, r is a random string of hash function's output length. Even low quality r (weak entropy or shorter length) is recommended as they contribute "significantly" to the security of the OKM. Without or with a low-entropy, non-secret r, if an attacker can influence the IKMs source in a way that specifically exploits HKDF-Extract's underlying hash function (finding a collision or a specific bias), XTR provides no protection. A random r, even if fixed by the application (for example, random number generators using r as seed), would strengthen protections for that specific extractor session. In such a setting, sufficiently long IKMs also provide better entropy extraction. However, allowing the attacker to influence enough of the IKM after seeing r may result in a completely insecure KDF. HKDF-Extract is the result of HMAC with r as the key (all zeros up to length of the underlying extractor hash function, if not provided) and the IKM as the message. The underlying hash function used for HKDF-Extract step may be different to the one used by HKDF-Expand. It is recommended that HKDF-Extract uses strongest hash function available to the application, as it "concentrates" the entropy already present in IKM but may not necessarily "add" to it. Truncated output from a stronger underlying hash function for XTR (for example, SHA512/256) offers stronger extraction properties. The attacker is assumed to have partial knowledge about IKM (publicly known values in the case of Diffie-Hellman) or partial control over it (entropy pools). HKDF-Extract may be skipped if the IKM is itself a cryptographically strong key (and hence can assume the role of PRK), though it is recommended that HKDF-Extract be applied for the sake of compatibility with the general case, especially if r is available to the application. === HKDF-Expand === HKDF-Expand (PRF) takes the PRK (or any random key-derivation key if HKDF-Extract step is skipped), optional info (CTXinfo), and a length (L), to generate output key material (OKM) of length L. Multiple OKMs can be generated from a single PRK by using different values for CTXinfo, which must be "independent" of the IKM passed in HKDF-Extract. Even if an attacker, who knows r and some auxillary information about the secret IKM, can force the use of the same IKM (and PRK, by extension), in two or more HKDF-Expand contexts (represented by CTXinfo), the OKMs output are computationally independent (leak no useful information on each other). HKDF-Expand, acting as a variable-output-length pseudorandom function (PRF) keyed on PRK, calls HMAC on CTXinfo as the message (empty string, if unspecified) appended to a 8-bit counter i initialized to 1. Subsequent calls to HMAC are chained in "feedback mode" by prepending the previous HMAC output to CTXinfo and incrementing i. OKM is a function of the output size (k bits) of HMAC's underlying hash function; i.e., SHA-256 outputs OKM in segments of k=256 bits for up to a maximum of length i × k bits (255 × 256 bits = 8160 bytes) truncated to desired length L. HKDF-Expand may be skipped if PRK is at least desired length L, though it is recommended that HKDF-Expand be applied for additional "smoothing" of the OKM. == Standardization == HKDF was proposed as a building block in various protocols and applications, as well as to discourage the proliferation of multiple KDF mechanisms by its authors. It is formally described in RFC 5869 with detailed analysis in a paper published in 2010. NIST SP800-56Cr2 specifies a parameterizable extract-then-expand scheme, noting that RFC 5869 HKDF is a version of it and citing its paper for the rationale for the recommendations' extract-and-expand mechanisms. == Applications == HKDF is used in the Signal Protocol for end-to-end encrypted messaging where it generates the message keys, in conjunction with the triple Elliptic-curve Diffie-Hellman handshake (X3DH) key agreement protocol. Signal's "Secure Value Recovery" and "Sealed Sender" are based on HKDF. HKDF is a main component in the Noise Protocol Framework, Message Layer Security, and is used in widely deployed protocols like IPsec Internet Key Exchange and TLS 1.3. The "multi-purpose" nature of HKDF is meant to serve applications that require key extraction, key expansion, and key hierarchies in key wrapping, key exchange, PRNG, and password-based key derivation schemes. == Implementations == There are implementations of HKDF for C#, Go, Java, JavaScript, Perl, PHP, Python, Ruby, Rust, and other programming languages. RFC6234 lays out a reference C implementation of HKDF based on the Secure Hash Standard. === Example in Python ===
Instagram egg
The Instagram egg is a photo of an egg posted by the account @world_record_egg on the social media platform Instagram. It became a global phenomenon and an internet meme within days of its publication on 4 January 2019. It is the second most-liked Instagram post and was the most-liked Instagram post from 14 January 2019 until 20 December 2022, when it was overtaken by Lionel Messi's post showing him and his teammates celebrating after Argentina won the 2022 FIFA World Cup. The owner of the account was revealed to be Chris Godfrey, a British advertising creative, who later worked with his two friends Alissa Khan-Whelan and CJ Brown on a Hulu commercial featuring the egg, intended to raise mental health awareness. == Background == The photo was originally taken by Serghei Platanov, who then posted it to Shutterstock on 23 June 2015 with the title "eggs isolated on white background". == History == On 4 January 2019, the @world_record_egg account was created, and posted an image of a bird egg with the caption, "Let's set a world record together and get the most liked post on Instagram. Beating the current world record held by Kylie Jenner (18 million)! We got this." Jenner's previous record, the first photo of her daughter Stormi, had garnered a total of 18.4 million likes. The post quickly reached 18.4 million likes in just under 10 days, becoming the most-liked Instagram post at the time. It then continued to rise over 45 million likes in the next 48 hours, surpassing the "Despacito" music video and taking the world record for the most-liked online post (on any media platform) in history. After the account became verified on 14 January 2019, the post rose in popularity and likes, which snowballed into coverage in various media outlets. By 18 March 2019, the post had accumulated over 53.3 million likes, nearly three times the previous record of 18.4 million. It posted frequent updates for a few days in the form of Instagram Stories. Alongside the like tally, as of January 2023 the post has 3.8 million comments. Several individuals tried to claim that they were the account's creator, the claims being dismissed by "the egg" on Instagram direct messages. On 3 February 2019, the creator of the Instagram egg was revealed by Hulu and The New York Times to be Chris Godfrey, a British advertising creative. Alissa Khan-Whelan, his colleague, was also outed. On 18 January 2019, the account posted a second picture of an egg, almost identical to the first one apart from a small crack at the top left. As of 25 February 2019, the post accumulated 11.8 million likes. On 22 January 2019, the account posted a third picture of an egg, this time having two larger cracks. In less than 25 minutes, the post accumulated 1 million likes, and by 25 February 2019, it had accumulated 9.5 million likes. On 29 January 2019, a fourth picture of an egg was posted to the account which has another large crack on the right hand side, attracting 7.6 million likes by 25 February 2019. On 1 February 2019, a fifth picture of an egg was posted with stitching like that of a football, referencing the upcoming Super Bowl. That post had accumulated 6.5 million likes by 25 February 2019. The account promised that it would reveal what was inside the egg on 3 February, on the subscription video on demand service Hulu. The Hulu Instagram egg reveal was used to promote an animation about a mental health campaign. A caption from the clip read, "Recently I've started to crack, the pressure of social media is getting to me. If you're struggling too, talk to someone." The video was later posted on the @world_record_egg Instagram account, and this post received over 33 million views by May 2019. As of May 2020, it had received over 41 million views. On 16 July 2019, Chris Godfrey (the creator of the account) was listed as one of the top 25 most influential people on the internet. On 20 December 2022, the record for the most-liked Instagram post was surpassed by a post from Argentine footballer Lionel Messi, showing him and his teammates celebrating after winning the 2022 FIFA World Cup with their national team. The world record egg responded to being overtaken in likes by Messi with "Today [Lionel Messi] has taken the crown, for now. But I'm still left with one question… Who is the greatest of all time – Cristiano Ronaldo or Leo Messi?" The account sold to Dubai-based investor Mustafa El Fishawy in April 2024 for an undisclosed seven-figure sum. Reed Smith, who advised Godfrey, Brown, and Khan-Whelan in the transaction, stated they opted to sell it to "focus on new ventures." On 3 June, @world_record_egg posted an egg with the flag of Palestine in support of the country during the Gaza war; the post's caption described it as an "Egg for Peace" and hoped to "set a new world record together and get the most liked post on Instagram for a good cause." == Reception == In response to breaking the world record for the most-liked Instagram post, the account's owner wrote "This is madness. What a time to be alive." Hours later, Jenner posted a video on Instagram of her cracking open an egg and pouring its yolk onto the ground, with the caption: "Take that little egg." Pundits pontificated on the meaning of the egg picture's dominance over social media's "first family". As Vogue observed, tapping a heart pictogram is easy, and eggs are "lovable". More pointedly: [T]he attention economy is a scam based on requiring little to no labor from both producer and consumer despite commanding the most space, and therefore value, in our digital lives... but it very well could be: As a metaphor for the fragility of the influencer ecosystem, the egg has broken the Internet. The significance of the event and its massive republishing are a topic of discussion. A University of Westminster researcher of internet memes compared it to the movement to name a scientific research vessel in the United Kingdom as Boaty McBoatface. The Instagrammer's success is a rare victory for the unpaid viral campaign on social media. "There is a bit of an anti-celebrity revolt here – 'look what we can do with a simple egg'" The researcher suggests that the accomplishment of becoming such a widely heralded unpaid viral post may become increasingly rare, as social networks rely more on paid and business promotion. The post's spread has been characterized as a populist backlash against "consumerism" and is seen by some as a triumph of community over celebrity. However, propelled by their popular success, the creators promised to release 'egg-centric' memorabilia. Hundreds of games based on the Instagram egg have appeared on Apple's App Store. The creators of the Instagram egg also reached a deal to promote Hulu.
Codebook
A codebook is a type of document used for gathering and storing cryptography codes. Originally, codebooks were often literally books, but today "codebook" is a byword for the complete record of a series of codes, regardless of physical format. == Cryptography == In cryptography, a codebook is a document used for implementing a code. A codebook contains a lookup table for coding and decoding; each word or phrase has one or more strings which replace it. To decipher messages written in code, corresponding copies of the codebook must be available at either end. The distribution and physical security of codebooks presents a special difficulty in the use of codes compared to the secret information used in ciphers, the key, which is typically much shorter. The United States National Security Agency documents sometimes use codebook to refer to block ciphers; compare their use of combiner-type algorithm to refer to stream ciphers. Codebooks come in two forms, one-part or two-part: In one-part codes, the plaintext words and phrases and the corresponding code words are in the same alphabetical order. They are organized similar to a standard dictionary. Such codes are half the size of two-part codes but are more vulnerable since an attacker who recovers some code word meanings can often infer the meaning of nearby code words. One-part codes may be used simply to shorten messages for transmission or have their security enhanced with superencryption methods, such as adding a secret number to numeric code words. In two-part codes, one part is for converting plaintext to ciphertext, the other for the opposite purpose. They are usually organized similarly to a language translation dictionary, with plaintext words (in the first part) and ciphertext words (in the second part) presented like dictionary headwords. The earliest known use of a codebook system was by Gabriele de Lavinde in 1379 working for the Antipope Clement VII. Two-part codebooks go back as least as far as Antoine Rossignol in the 1800s. From the 15th century until the middle of the 19th century, nomenclators (named after nomenclator) were the most used cryptographic method. Codebooks with superencryption were the most used cryptographic method of World War I. The JN-25 code used in World War II used a codebook of 30,000 code groups superencrypted with 30,000 random additives. The book used in a book cipher or the book used in a running key cipher can be any book shared by sender and receiver and is different from a cryptographic codebook. == Social sciences == In social sciences, a codebook is a document containing a list of the codes used in a set of data to refer to variables and their values, for example locations, occupations, or clinical diagnoses. == Data compression == Codebooks were also used in 19th- and 20th-century commercial codes for the non-cryptographic purpose of data compression. Codebooks are used in relation to precoding and beamforming in mobile networks such as 5G and LTE. The usage is standardized by 3GPP, for example in the document TS 38.331, NR; Radio Resource Control (RRC); Protocol specification.
PerfKitBenchmarker
PerfKit Benchmarker is an open source benchmarking tool used to measure and compare cloud offerings. PerfKit Benchmarker is licensed under the Apache 2 license terms. PerfKit Benchmarker is a community effort involving over 500 participants including researchers, academic institutions and companies together with the originator, Google. == General == PerfKit Benchmarker (PKB) is a community effort to deliver a repeatable, consistent, and open way of measuring Cloud Performance. It supports a growing list of cloud providers including: Alibaba Cloud, Amazon Web Services, CloudStack, DigitalOcean, Google Cloud Platform, Kubernetes, Microsoft Azure, OpenStack, Rackspace, IBM Bluemix (Softlayer). In addition to Cloud Providers to supports container orchestration including Kubernetes [1] and Mesos [2] and local "static" workstations and clusters of computers [3]. The goal is to create an open source living benchmark [framework] that represents how Cloud developers are building applications, evaluating Cloud alternatives, learning how to architect applications for each cloud. Living because it will change and morph quickly as developers change. PerfKit Benchmarker measures the end to end time to provision resources in the cloud, in addition to reporting on the most standard metrics of peak performance, e.g.: latency, throughput, time-to-complete, IOPS. PerfKit Benchmarker reduces the complexity in running benchmarks on supported cloud providers by unified and simple commands. It's designed to operate via vendor provided command line tools. PerfKit Benchmarker contains a canonical set of public benchmarks. All benchmarks are running with default/initial state and configuration (Not tuned to in favor of any providers). This provides a way to benchmark across cloud platforms, while getting a transparent view of application throughput, latency, variance, and overhead. == History == PerfKit Benchmarker (PKB) was started by Anthony F. Voellm, Alain Hamel, and Eric Hankland at Google in 2014. Once an initial "alpha" was in place Anthony F. Voellm and Ivan Santa Maria Filho built a community including ARM, Broadcom, Canonical, CenturyLink, Cisco, CloudHarmony, CloudSpectator, EcoCloud@EPFL, Intel, Mellanox, Microsoft, Qualcomm Technologies, Inc., Rackspace, Red Hat, Tradeworx Inc., and Thesys Technologies LLC. This community worked together behind the scenes in a private GitHub project to create an open way to measure cloud performance. This community released the first public "beta" was released on February 11, 2015, and announced in a blog post at which point the GitHub project was open to everyone. After almost a year and with large adaption (600+ participants on GitHub) the V1.0.0 was released along with a detailed architectural design on December 10, 2015. == Benchmarks == A list of available benchmarks from PerfKitBenchmarker: (The latest set of benchmarks can be found at GitHub readme file.) == Industry participants == Since Google open sourced the PerfKitBenchmarker, it became a community effort from over 30 leading researchers, academic schools and industry companies. Those organizations include: ARM, Broadcom, Canonical, CenturyLink, Cisco, CloudHarmony, Cloud Spectator, EcoCloud@EPFL, Intel, Mellanox, Microsoft, Qualcomm Technologies, Rackspace, Red Hat, and Thesys Technologies. In addition, Stanford and MIT are leading quarterly discussions on default benchmarks and settings proposed by the community. EcoCloud@EPFL is integrating CloudSuite into PerfKit Benchmarker. == Example runs == On Google Cloud Platform On AWS On Azure On Rackspace On a local machine
Ciphertext expansion
In cryptography, the term ciphertext expansion refers to the length increase of a message when it is encrypted. Many modern cryptosystems cause some degree of expansion during the encryption process, for instance when the resulting ciphertext must include a message-unique Initialization Vector (IV). Probabilistic encryption schemes cause ciphertext expansion, as the set of possible ciphertexts is necessarily greater than the set of input plaintexts. Certain schemes, such as Cocks Identity Based Encryption, or the Goldwasser-Micali cryptosystem result in ciphertexts hundreds or thousands of times longer than the plaintext. Ciphertext expansion may be offset or increased by other processes which compress or expand the message, e.g., data compression or error correction coding. == Reasons why Ciphertext expansion can occur == === Probabilistic Encryption === Probabilistic encryption schemes, such as the Goldwasser-Micali cryptosystem, necessarily produce ciphertexts that are longer than the original plaintexts. This is because the set of possible ciphertexts must be larger than the set of plaintexts to achieve semantic security. === Initialization Vectors (IVs) === Many block cipher modes of operation, like Cipher Block Chaining (CBC), require the use of an Initialization Vector (IV) that is unique for each message. The IV is typically appended to the ciphertext, resulting in expansion. === Redundancy and Error Correction === Some cryptographic schemes intentionally introduce redundancy or error correction codes into the ciphertext to protect against tampering or transmission errors. This added data increases the ciphertext size. === Specific Cryptosystems === Certain cryptographic schemes, such as Cocks Identity-Based Encryption, can produce ciphertexts that are hundreds or thousands of times longer than the original plaintext. This extreme expansion is a design choice to achieve the desired security properties. Ciphertext expansion can be offset or increased by other processes that compress or expand the message, such as data compression or error correction coding. The overall impact on message size depends on the relative strengths of these competing effects.