In cryptography, format-preserving encryption (FPE), refers to encrypting in such a way that the output (the ciphertext) is in the same format as the input (the plaintext). The meaning of "format" varies. Typically only finite sets of characters are used; numeric, alphabetic or alphanumeric. For example: Encrypting a 16-digit credit card number so that the ciphertext is another 16-digit number. Encrypting an English word so that the ciphertext is another English word. Encrypting an n-bit number so that the ciphertext is another n-bit number (this is the definition of an n-bit block cipher). For such finite domains, and for the purposes of the discussion below, the cipher is equivalent to a permutation of N integers {0, ... , N−1} where N is the size of the domain. == Motivation == === Restricted field lengths or formats === One motivation for using FPE comes from the problems associated with integrating encryption into existing applications, with well-defined data models. A typical example would be a credit card number, such as 1234567812345670 (16 bytes long, digits only). Adding encryption to such applications might be challenging if data models are to be changed, as it usually involves changing field length limits or data types. For example, output from a typical block cipher would turn credit card number into a hexadecimal (e.g.0x96a45cbcf9c2a9425cde9e274948cb67, 34 bytes, hexadecimal digits) or Base64 value (e.g. lqRcvPnCqUJc3p4nSUjLZw==, 24 bytes, alphanumeric and special characters), which will break any existing applications expecting the credit card number to be a 16-digit number. Apart from simple formatting problems, using AES-128-CBC, this credit card number might get encrypted to the hexadecimal value 0xde015724b081ea7003de4593d792fd8b695b39e095c98f3a220ff43522a2df02. In addition to the problems caused by creating invalid characters and increasing the size of the data, data encrypted using the CBC mode of an encryption algorithm also changes its value when it is decrypted and encrypted again. This happens because the random seed value that is used to initialize the encryption algorithm and is included as part of the encrypted value is different for each encryption operation. Because of this, it is impossible to use data that has been encrypted with the CBC mode as a unique key to identify a row in a database. FPE attempts to simplify the transition process by preserving the formatting and length of the original data, allowing a drop-in replacement of plaintext values with their ciphertexts in legacy applications. == Comparison to truly random permutations == Although a truly random permutation is the ideal FPE cipher, for large domains it is infeasible to pre-generate and remember a truly random permutation. So the problem of FPE is to generate a pseudorandom permutation from a secret key, in such a way that the computation time for a single value is small (ideally constant, but most importantly smaller than O(N)). == Comparison to block ciphers == An n-bit block cipher technically is a FPE on the set {0, ..., 2n-1}. If an FPE is needed on one of these standard sized sets (for example, n = 64 for DES and n = 128 for AES) a block cipher of the right size can be used. However, in typical usage, a block cipher is used in a mode of operation that allows it to encrypt arbitrarily long messages, and with an initialization vector as discussed above. In this mode, a block cipher is not an FPE. == Definition of security == In cryptographic literature (see most of the references below), the measure of a "good" FPE is whether an attacker can distinguish the FPE from a truly random permutation. Various types of attackers are postulated, depending on whether they have access to oracles or known ciphertext/plaintext pairs. == Algorithms == In most of the approaches listed here, a well-understood block cipher (such as AES) is used as a primitive to take the place of an ideal random function. This has the advantage that incorporation of a secret key into the algorithm is easy. Where AES is mentioned in the following discussion, any other good block cipher would work as well. === The FPE constructions of Black and Rogaway === Implementing FPE with security provably related to that of the underlying block cipher was first undertaken in a paper by cryptographers John Black and Phillip Rogaway, which described three ways to do this. They proved that each of these techniques is as secure as the block cipher that is used to construct it. This means that if the AES algorithm is used to create an FPE algorithm, then the resulting FPE algorithm is as secure as AES because an adversary capable of defeating the FPE algorithm can also defeat the AES algorithm. Therefore, if AES is secure, then the FPE algorithms constructed from it are also secure. In all of the following, E denotes the AES encryption operation that is used to construct an FPE algorithm and F denotes the FPE encryption operation. ==== FPE from a prefix cipher ==== One simple way to create an FPE algorithm on {0, ..., N-1} is to assign a pseudorandom weight to each integer, then sort by weight. The weights are defined by applying an existing block cipher to each integer. Black and Rogaway call this technique a "prefix cipher" and showed it was provably as good as the block cipher used. Thus, to create an FPE on the domain {0,1,2,3}, given a key K apply AES(K) to each integer, giving, for example, weight(0) = 0x56c644080098fc5570f2b329323dbf62 weight(1) = 0x08ee98c0d05e3dad3eb3d6236f23e7b7 weight(2) = 0x47d2e1bf72264fa01fb274465e56ba20 weight(3) = 0x077de40941c93774857961a8a772650d Sorting [0,1,2,3] by weight gives [3,1,2,0], so the cipher is F(0) = 3 F(1) = 1 F(2) = 2 F(3) = 0 This method is only useful for small values of N. For larger values, the size of the lookup table and the required number of encryptions to initialize the table gets too big to be practical. ==== FPE from cycle walking ==== If there is a set M of allowed values within the domain of a pseudorandom permutation P (for example P can be a block cipher like AES), an FPE algorithm can be created from the block cipher by repeatedly applying the block cipher until the result is one of the allowed values (within M). CycleWalkingFPE(x) { if P(x) is an element of M then return P(x) else return CycleWalkingFPE(P(x)) } The recursion is guaranteed to terminate. (Because P is one-to-one and the domain is finite, repeated application of P forms a cycle, so starting with a point in M the cycle will eventually terminate in M.) This has the advantage that the elements of M do not have to be mapped to a consecutive sequence {0,...,N-1} of integers. It has the disadvantage, when M is much smaller than P's domain, that too many iterations might be required for each operation. If P is a block cipher of a fixed size, such as AES, this is a severe restriction on the sizes of M for which this method is efficient. For example, an application may want to encrypt 100-bit values with AES in a way that creates another 100-bit value. With this technique, AES-128-ECB encryption can be applied until it reaches a value which has all of its 28 highest bits set to 0, which will take an average of 228 iterations to happen. ==== FPE from a Feistel network ==== It is also possible to make a FPE algorithm using a Feistel network. A Feistel network needs a source of pseudo-random values for the sub-keys for each round, and the output of the AES algorithm can be used as these pseudo-random values. When this is done, the resulting Feistel construction is good if enough rounds are used. One way to implement an FPE algorithm using AES and a Feistel network is to use as many bits of AES output as are needed to equal the length of the left or right halves of the Feistel network. If a 24-bit value is needed as a sub-key, for example, it is possible to use the lowest 24 bits of the output of AES for this value. This may not result in the output of the Feistel network preserving the format of the input, but it is possible to iterate the Feistel network in the same way that the cycle-walking technique does to ensure that format can be preserved. Because it is possible to adjust the size of the inputs to a Feistel network, it is possible to make it very likely that this iteration ends very quickly on average. In the case of credit card numbers, for example, there are 1015 possible 16-digit credit card numbers (accounting for the redundant check digit), and because the 1015 ≈ 249.8, using a 50-bit wide Feistel network along with cycle walking will create an FPE algorithm that encrypts fairly quickly on average. === The Thorp shuffle === A Thorp shuffle is like an idealized card-shuffle, or equivalently a maximally-unbalanced Feistel cipher where one side is a single bit. It is easier to prove security for unbalanced Feistel ciphers than for balanced ones. === VIL mode === For domain sizes that are a power of two, and an existing block cipher with a smaller bl
Yap (company)
Yap Speech Cloud was a multimodal speech recognition system developed by American technology company Yap Inc. It offered a fully cloud-based speech-to-text transcription platform that was used by customers such as Microsoft. The Company was a contestant at the inaugural TechCrunch conference and was subsequently acquired by Amazon in September 2011 to help develop products such as Alexa Voice Service, Echo, and Fire TV.
Blitter object
A blitter object (Bob) is a graphical element (GEL) used by the Amiga computer. Bobs are hardware sprite-like objects, movable on the screen with the help of the blitter coprocessor. == Overview == The AmigaOS GEL system consists of VSprites, Bobs, AnimComps (animation components) and AnimObs (animation objects), each extending the preceding with additional functionality. While VSprites are a virtualization of hardware sprites Bobs are drawn into a playfield by the blitter, saving and restoring the background of the GEL as required. The Bob with the highest video priority is the last one to be drawn, which makes it appear to be in front of all other Bobs. In contrast to hardware sprites Bobs are not limited in size and number. Bobs require more processing power than sprites, because they require at least one DMA memory copy operation to draw them on the screen. Sometimes three distinct memory copy operations are needed: one to save the screen area where the Bob would be drawn, one to actually draw the Bob, and one later to restore the screen background when the Bob moves away. An AnimComp adds animation to a Bob and an AnimOb groups AnimComps together and assigns them velocity and acceleration.
Text Database and Dictionary of Classic Mayan
The project Text Database and Dictionary of Classic Mayan (abbr. TWKM) promotes research on the writing and language of pre-Hispanic Maya culture. It is housed in the Faculty of Arts at the University of Bonn and was established with funding from the North Rhine-Westphalian Academy of Sciences, Humanities and the Arts. The project has a projected run-time of fifteen years and is directed by Nikolai Grube from the Department of Anthropology of the Americas at the University of Bonn. The goal of the project is to conduct computer-based studies of all extant Maya hieroglyphic texts from an epigraphic and cultural-historical standpoint, and to produce and publish a database and a comprehensive dictionary of the Classic Mayan language. == Subject of the Project == The text database, as well as the dictionary that will be compiled by the conclusion of the project, will be assembled based on all known texts from the pre-Hispanic Maya culture. These texts were produced and used between approximately the third century B.C. through A.D. 1500, in a region that today includes parts of the countries of Mexico, Guatemala, Belize, and Honduras. The thousands of hieroglyphic inscriptions on monuments, ceramics, or daily objects that have survived into the present offer insight into the language's vocabulary and structure. The project's database and dictionary will digitally represent original spellings using the logo-syllabic Maya hieroglyphs, as well as their transcription and transliteration in the Roman alphabet. The data will be additionally annotated with various epigraphic analyses, translations, and further object-specific information. == Project Partners == TWKM will employ digital technologies in order to compile and make available the data and metadata, as well as to publish the project's research results. The project thereby methodologically positions itself in the field of the digital humanities. The project will be conducted in cooperation with the project partners (below), the research association for the eHumanities TextGrid, as well as the University and Regional Library of Bonn (ULB). The working environment that is currently under construction, in which the data and metadata will be compiled and annotated, will be realized in theTextGrid Laboratory, a software of the virtual research environment. A further component of this software, the TextGrid Repository, will make the data that are authorized for publication freely available online and ensure their long-term storage. The tools for data compilation and annotation attained from the modularly constructed and extended TextGrid lab thereby provide all the necessary materials for facilitating the research team's the typical epigraphic workflow. The workflow usually begins by documenting the texts and the objects on which they are preserved, and by compiling descriptive data. It then continues with the various levels of epigraphic and linguistic analysis, and concludes in the best case scenario with a translation of the analyzed inscription and a corresponding publication. In cooperation with the ULB, selected data will additionally be made available. The project's Virtual Inscription Archive will present online, in the Digital Collections of the ULB, hieroglyphic inscriptions selected from the published data in the repository, including an image of and brief information about the texts and the objects on which they are written, epigraphic analysis, and translation. == Project Goal == One of the project's goals is to produce a dictionary of Classic Mayan, in both digital and print form, towards the end of the project run-time. Additionally, a database with a corpus of inscriptions, including their translations and epigraphic analyses, will be made freely available online. The database furthermore will provide an ontology-like link of the contextual object data with the inscriptions and with each other, thereby allowing a cultural-historical arrangement of all contents within the periods of pre-Hispanic Maya culture. The contents of the database are additionally linked to citations of relevant literature. As a result, the database will also make freely available to both the scientific community and other interested parties a bibliography representing the research history and a base of knowledge concerning ancient Maya culture and script. In addition, the Classic Maya script, in its temporally defined stages of language development, will be gathered into and documented in a comprehensive language corpus with the aid of the information gathered by the project. In collaboration with all project participants, the corpus data can be used, together with the aid of various comparable analyses and also computational linguistic methods, such as inference-based methods, to confirm readings of some hieroglyphs that are currently only partially confirmed, and to eventually completely decipher the Classic Maya script.
Cryptographic module
A cryptographic module is a component of a computer system that securely implements cryptographic algorithms, typically with some element of tamper resistance. NIST defines a cryptographic module as "The set of hardware, software, and/or firmware that implements security functions (including cryptographic algorithms), holds plaintext keys and uses them for performing cryptographic operations, and is contained within a cryptographic module boundary." Hardware security modules, including secure cryptoprocessors, are one way of implementing cryptographic modules. Standards for cryptographic modules include FIPS 140-3 and ISO/IEC 19790.
Cumulus (software)
Cumulus is a digital asset management software designed for client/server system which is developed by Canto Software. The product makes use of metadata for indexing, organizing, and searching. == History == Cumulus was first released as a Macintosh application in 1992, and was named by Apple Computer as the "Most Innovative Product of 1992". Cumulus introduced search capabilities beyond those available in the Macintosh at the time, particularly relating to thumbnails. Cumulus 1.0 was a single-user product with no network capabilities. Among the main features of Cumulus 1.0, the search function automatically generated previews and contained support for the included AppleTalk – Peer-to-Peer – network. Cumulus 2.5 was available in five different languages and received the 1993 MacUser magazine Eddy award for "Best Publishing & Graphics Utility". In 1995, Canto introduced the scanner software "Cirrus" to focus on the development of Cumulus. Cumulus 3, released in 1996, introduced a server version for the first time and contained the possibility to spread files over the Internet via the "Web Publisher". Since Apple offered Cumulus 3 with its "Workgroup Server" as a bundle, Cumulus became one of the leading digital asset management systems. Cumulus 4 was the first version that was network-ready, and was available for Macintosh, Windows and UNIX operating systems allowing for cross-platform file sharing. Released in 1998, the support of Solaris was discounted later. Cumulus 5 modified the software core to use an open architecture providing an API to external systems and databases. The open architecture of Cumulus 5 also enabled a more functional bridge between Cumulus and the Internet. Cumulus 6 introduced Embedded Java Plugin (EJP) which allowed system integrators to build custom Java plug-ins in order to extend the functionality of the Cumulus client. Cumulus 6.5 marked the end of the Cumulus Single User Edition product, which was licensed to MediaDex for further development and distribution. Cumulus 7 was introduced summer of 2006. Cumulus 8 was released in June 2009, with new indexing capabilities taking advantage of multicore/multiprocessor systems, and ability to manage a wider variety of file formats. Cumulus 8.5 was released in May 2011. Support was added for multilingual metadata, sometimes referred to as "World Metadata." Cumulus Sites was updated to support metadata editing and file uploads. Cumulus 8.6 was released in July 2012, and contains an updated user interface for the administration of Cumulus Sites and additional features for web-based administration of Cumulus. Other additions include features for collaboration links, multi-language support and automated version control. Cumulus 9 was released in September 2013 and introduced a new Web Client User Interface and the Cumulus Video Cloud. The Cumulus Web Client UI was redesigned to provide users with a modern, easy-to-use interface to support and guide the user while addressing modern business needs. The Cumulus Video Cloud extends the Cumulus video handling capabilities to add conversion and global streaming. Cumulus 9 also saw the addition of upload collection links which allow external collaborators to drag and drop files directly into Cumulus without needing a Cumulus account. Cumulus 9.1 was released in May 2014 and introduced the Adobe Drive Adapter for Cumulus which allows users to browse and search digital assets in Cumulus directly from Adobe work environments such as Photoshop, InDesign, Illustrator, Premier and other Adobe applications. Cumulus 10 (Cumulus X) was released July 2015 and introduced two mobile-friendly products: the Cumulus app and Portals. The Cumulus app on iOS was designed to allow users to collaborate either on an iPhone or iPad. Portals is the read-only version of the Cumulus Web Client where users can work with assets that admins allow. Cumulus 10.1 was introduced in January 2016 and included the InDesign Client integration where users can work with Adobe InDesign while accessing their assets from Cumulus. Cumulus 10.2 was introduced in September 2016 and brought the Media Delivery Cloud using Amazon Web Services (AWS). It allows users to manage their media rendition in a single source and distribute media files globally across different channels and devices. Cumulus 10.2.3 was released in February 2017 and came with a "crop and customize photos" feature for Portals and the Web Client. == Product overview == The cataloging of the file via upload into the archive is where Cumulus transfers maximum information about the file from the metadata. For image or photo files, this is typically Exif and IPTC data. The metadata is mainly used to search the archive. The use of embargo data supports license management for copyrighted material. The managed files can be cataloged and their usage can be set. The indexing is based on a predefined taxonomy, which is governed by the internal rules of the organization or by industry standards. You can specify whether files can only be used for specific purposes or only by certain groups of people. The production management system includes version management for files. Via the publication function, the files can be distributed directly via links or e-mails. It's also possible to access from the outside via the Cumulus Portals web interface, which allows a read access to released content from the catalog. There are different variants, starting with the "Workgroup archive server" up to the "Enterprise Business Server" for large companies. Both server and client are extensible through a Java-based plug-in architecture. Since version 7.0, there is a web application based on Ajax with a separate user interface. For access to the Cumulus catalog on mobile, there has been an application for Apple devices based on iOS since 2010. == Miscellaneous == In 2015, Cumulus developer Canto established the first Canto digital asset management (DAM) event. The event is held annually in Berlin. The Henry Stewart team has been hosting DAM conferences since 2006.
Texture atlas
In computer graphics, a texture atlas (also called a spritesheet or an image sprite in 2D game development) is an image containing multiple smaller images, usually packed together to reduce overall dimensions. An atlas can consist of uniformly-sized images or images of varying dimensions. A sub-image is drawn using custom texture coordinates to pick it out of the atlas. == Benefits == In an application where many small textures are used frequently, it is often more efficient to store the textures in a texture atlas which is treated as a single unit by the graphics hardware. This reduces both the disk I/O overhead and the overhead of a context switch by increasing memory locality. Careful alignment may be needed to avoid bleeding between sub textures when used with mipmapping and texture compression. In web development, images are packed into a sprite sheet to reduce the number of image resources that need to be fetched in order to display a page. == Gallery ==