PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40
Committee Note 02
16 November 2014
Specification URIs
This version:
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.doc (Authoritative)
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.pdf
Previous version:
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn01/pkcs11-ug-v2.40-cn01.doc (Authoritative)
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn01/pkcs11-ug-v2.40-cn01.html
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn01/pkcs11-ug-v2.40-cn01.pdf
Latest version:
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.doc (Authoritative)
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html
http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.pdf
Technical Committee:
Chairs:
Robert Griffin (robert.griffin@rsa.com), EMC Corporation
Valerie Fenwick (valerie.fenwick@oracle.com), Oracle
Editors:
John Leiseboer (jl@quintessencelabs.com), QuintessenceLabs Pty Ltd.
Robert Griffin (robert.griffin@rsa.com), EMC Corporation
Related work:
Abstract:
This document provides guidance on using PKCS #11 Version 2.40.
Status:
This document was last revised or approved by the OASIS PKCS 11 TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.
Technical Committee members should send comments on this document to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at https://www.oasis-open.org/committees/pkcs11/.
Citation format:
When referencing this document the following citation format should be used:
[PKCS11-UG-v2.40]
PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40. Edited by John Leiseboer and Robert Griffin. 16 November 2014. OASIS Committee Note 02. http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/cn02/pkcs11-ug-v2.40-cn02.html. Latest version: http://docs.oasis-open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html.
Copyright © OASIS Open 2014. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

Table of Contents
1.1 Description of this Document
1.4 References (non-normative)
2.5 Applications and their use of Cryptoki
2.5.2 Applications and processes
2.5.3 Applications and threads
2.6.2 Read-only session states
2.6.3 Read/write session states
2.6.4 Permitted object accesses by sessions
2.6.6 Session handles and object handles
2.6.7 Capabilities of sessions
2.6.8 Example of use of sessions
4.1 Operations, sessions, and threads
4.2 Multiple Application Access Behavior
4.3 Objects, attributes, and templates
5 Comparison of Cryptoki and other APIs
6 Deprecated PKCS #11 Functionality
6.1 Secondary authentication (Deprecated)
6.2 Method for Exposing Multiple-PINs on a Token Through Cryptoki (deprecated)
6.3 Non-Normative Token Profiles
6.3.1 Description of this Section
6.3.2 Government authentication-only
6.3.3 Cellular Digital Packet Data
This PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40 is intended to complement [PKCS11-Base], [PKCS11-Curr], [PKCS11-Hist] and [PKCS11-Prof] by providing guidance on how to implement the PKCS #11 interface most effectively. In particular, it includes the following guidance:
· General overview information and clarification of assumptions and requirements that drive or influence the design of PKCS #11 and the implementation of PKCS #11-compliant solutions.
· Specific recommendations for implementation of particular PKCS #11 functionality.
· Functionality considered for inclusion in PKCS #11 V2.40, but deferred to subsequent versions of the standard.
Guidance regarding conformant PKCS #11 implementations is provided in [PKCS11-Prof].
For a list of terminologies refer to [PKCS11-Spec].
This is a non-standars track document and does not contain normative references.
[FORTEZZA] FORTEZZA CIPG Application Programming Interface http://cryptome.org/jya/fortezza.htm.
[GCS-API] Generic Cryptographic Service API Base (GCS-API). X/Open Preliminary Specifications. June 1996. http://archive.opengroup.org/publications/archive/CDROM/p442.pdf.
[PKCS11-Base] PKCS #11 Cryptographic Token Interface Base Specification Version 2.40. Edited by Susan Gleeson and Chris Zimman. Latest version. http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html.
[PKCS11-Curr] PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 2.40. Edited by Susan Gleeson and Chris Zimman. Latest version. http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html.
[PKCS11-Hist] PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40. Edited by Susan Gleeson and Chris Zimman. Latest version. http://docs.oasis-open.org/pkcs11/pkcs11-hist/v2.40/pkcs11-hist-v2.40.html.
[PKCS11-Prof] PKCS #11 Cryptographic Token Interface Profiles Version 2.40. Edited by Tim Hudson. Latest version. http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v2.40/pkcs11-profiles-v2.40.html.
[PKCS11_V2.11] PKCS #11 Cryptographic Token Interface Standard Version 2.11, Revision 1. November 2001. ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs-11v2-11r1.doc.
Portable computing devices such as smart cards, PCMCIA cards, and smart diskettes are ideal tools for implementing public-key cryptography, as they provide a way to store the private-key component of a public-key/private-key pair securely, under the control of a single user. With such a device, a cryptographic application, rather than performing cryptographic operations itself, utilizes the device to perform the operations, with sensitive information such as private keys never being revealed. As more applications are developed for public-key cryptography, a standard programming interface for these devices becomes increasingly valuable. This standard addresses this and other needs.
Cryptoki's general model is illustrated in the following figure. The model begins with one or more applications that need to perform certain cryptographic operations, and ends with one or more cryptographic devices, on which some or all of the operations are actually performed. A user may or may not be associated with an application.
Figure 1: General Cryptoki Model
Cryptoki provides an interface to one or more cryptographic devices that are active in the system through a number of “slots”. Each slot, which corresponds to a physical reader or other device interface, may contain a token. A token is typically “present in the slot” when a cryptographic device is present in the reader. Of course, since Cryptoki provides a logical view of slots and tokens, there may be other physical interpretations. It is possible that multiple slots may share the same physical reader. The point is that a system has some number of slots, and applications can connect to tokens in any or all of those slots.
A cryptographic device can perform some cryptographic operations, following a certain command set; these commands are typically passed through standard device drivers, for instance PCMCIA card services or socket services. Cryptoki makes each cryptographic device look logically like every other device, regardless of the implementation technology. Thus the application need not interface directly to the device drivers (or even know which ones are involved); Cryptoki hides these details. Indeed, the underlying “device” may be implemented entirely in software (for instance, as a process running on a server)—no special hardware is necessary.
Cryptoki is likely to be implemented as a library supporting the functions in the interface, and applications will be linked to the library. An application may be linked to Cryptoki directly; alternatively, Cryptoki can be a so-called “shared” library (or dynamic link library), in which case the application would link the library dynamically. Shared libraries are fairly straightforward to produce in operating systems such as Microsoft Windows and OS/2, and can be achieved without too much difficulty in UNIX and DOS systems.
The dynamic approach certainly has advantages as new libraries are made available, but from a security perspective, there are some drawbacks. In particular, if a library is easily replaced, then there is the possibility that an attacker can substitute a rogue library that intercepts a user’s PIN. From a security perspective, therefore, direct linking is generally preferable, although code-signing techniques can prevent many of the security risks of dynamic linking. In any case, whether the linking is direct or dynamic, the programming interface between the application and a Cryptoki library remains the same.
The kinds of devices and capabilities supported will depend on the particular Cryptoki library. This standard specifies only the interface to the library, not its features. In particular, not all libraries will support all the mechanisms (algorithms) defined in this interface (since not all tokens are expected to support all the mechanisms), and libraries will likely support only a subset of all the kinds of cryptographic devices that are available. (The more kinds, the better, of course, and it is anticipated that libraries will be developed supporting multiple kinds of token, rather than just those from a single vendor.) It is expected that as applications are developed that interface to Cryptoki, standard library and token “profiles” will emerge.
Cryptoki’s logical view of a token is a device that stores objects and can perform cryptographic functions. Cryptoki defines three classes of object: data, certificates, and keys. A data object is defined by an application. A certificate object stores a certificate. A key object stores a cryptographic key. The key may be a public key, a private key, or a secret key; each of these types of keys has subtypes for use in specific mechanisms. This view is illustrated in the following figure:
Figure 2: Object Hierarchy
Objects are also classified according to their lifetime and visibility. “Token objects” are visible to all applications connected to the token that have sufficient permission, and remain on the token even after the “sessions” (connections between an application and the token) are closed and the token is removed from its slot. “Session objects” are more temporary: whenever a session is closed by any means, all session objects created by that session are automatically destroyed. In addition, session objects are only visible to the application which created them.
Further classification defines access requirements. Applications are not required to log into the token to view “public objects”; however, to view “private objects”, a user must be authenticated to the token by a PIN or some other token-dependent method (for example, a biometric device)..A token can create and destroy objects, manipulate them, and search for them. It can also perform cryptographic functions with objects. A token may have an internal random number generator.
It is important to distinguish between the logical view of a token and the actual implementation, because not all cryptographic devices will have this concept of “objects,” or be able to perform every kind of cryptographic function. Many devices will simply have fixed storage places for keys of a fixed algorithm, and be able to do a limited set of operations. Cryptoki's role is to translate this into the logical view, mapping attributes to fixed storage elements and so on. Not all Cryptoki libraries and tokens need to support every object type. It is expected that standard “profiles” will be developed, specifying sets of algorithms to be supported.
“Attributes” are characteristics that distinguish an instance of an object. In Cryptoki, there are general attributes, such as whether the object is private or public. There are also attributes that are specific to a particular type of object, such as a modulus or exponent for RSA keys.
This version of Cryptoki recognizes two token user types. One type is a Security Officer (SO). The other type is the normal user. Only the normal user is allowed access to private objects on the token, and that access is granted only after the normal user has been authenticated. Some tokens may also require that a user be authenticated before any cryptographic function can be performed on the token, whether or not it involves private objects. The role of the SO is to initialize a token and to set the normal user’s PIN (or otherwise define, by some method outside the scope of this version of Cryptoki, how the normal user may be authenticated), and possibly to manipulate some public objects. The normal user cannot log in until the SO has set the normal user’s PIN.
Other than the support for two types of user, Cryptoki does not address the relationship between the SO and a community of users. In particular, the SO and the normal user may be the same person or may be different, but such matters are outside the scope of this standard.
With respect to PINs that are entered through an application, Cryptoki assumes only that they are variable-length strings of characters from the set in [PKCS11-BASE] Table 3. Any translation to the device’s requirements is left to the Cryptoki library. The following issues are beyond the scope of Cryptoki:
· Any padding of PINs.
· How the PINs are generated (by the user, by the application, or by some other means).
PINs that are supplied by some means other than through an application (e.g., PINs entered via a PIN pad on the token) are even more abstract. Cryptoki knows how to wait (if need be) for such a PIN to be supplied and used, and little more.
To Cryptoki, an application consists of a single address space and all the threads of control running in it. An application becomes a “Cryptoki application” by calling the Cryptoki function C_Initialize from one of its threads; after this call is made, the application can call other Cryptoki functions. When the application has finished using Cryptoki, it calls the Cryptoki function C_Finalize and ceases to be a Cryptoki application.
In general, on most platforms, the previous paragraph means that an application consists of a single process.
Consider a UNIX process P which becomes a Cryptoki application by calling C_Initialize, and then uses the fork() system call to create a child process C. Since P and C have separate address spaces (or will when one of them performs a write operation, if the operating system follows the copy-on-write paradigm), they are not part of the same application. Therefore, if C needs to use Cryptoki, it needs to perform its own C_Initialize call. Furthermore, if C needs to be logged into the token(s) that it will access via Cryptoki, it needs to log into them even if P is already logged in, since P and C are completely separate applications.
In this particular case (when C is the child of a process which is a Cryptoki application), the behavior of Cryptoki is undefined if C tries to use it without its own C_Initialize call. Ideally, such an attempt would return the value CKR_CRYPTOKI_NOT_INITIALIZED; however, because of the way fork() works, insisting on this return value might have a bad impact on the performance of libraries. Therefore, the behavior of Cryptoki in this situation is left undefined. Applications should definitely not attempt to take advantage of any potential “shortcuts” which might (or might not!) be available because of this.
In the scenario specified above, C should actually call C_Initialize whether or not it needs to use Cryptoki; if it has no need to use Cryptoki, it should then call C_Finalize immediately thereafter. This (having the child immediately call C_Initialize and then call C_Finalize if the parent is using Cryptoki) is considered to be good Cryptoki programming practice, since it can prevent the existence of dangling duplicate resources that were created at the time of the fork() call; however, it is not required by Cryptoki.
Some applications will access a Cryptoki library in a multi-threaded fashion. Cryptoki enables applications to provide information to libraries so that they can give appropriate support for multi-threading. In particular, when an application initializes a Cryptoki library with a call to C_Initialize, it can specify one of four possible multi-threading behaviors for the library:
1. The application can specify that it will not be accessing the library concurrently from multiple threads, and so the library need not worry about performing any type of locking for the sake of thread-safety.
2. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must be able to use native operation system synchronization primitives to ensure proper thread-safe behavior.
3. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must use a set of application-supplied synchronization primitives to ensure proper thread-safe behavior.
4. The application can specify that it will be accessing the library concurrently from multiple threads, and the library must use either the native operating system synchronization primitives or a set of application-supplied synchronization primitives to ensure proper thread-safe behavior.
The 3rd and 4th types of behavior listed above are appropriate for multi-threaded applications that are not using the native operating system thread model. The application-supplied synchronization primitives consist of four functions for handling mutex (mutual exclusion) objects in the application’s threading model. Mutex objects are simple objects that can be in either of two states at any given time: unlocked or locked. If a call is made by a thread to lock a mutex that is already locked, that thread blocks (waits) until the mutex is unlocked; then it locks it and the call returns. If more than one thread is blocking on a particular mutex, and that mutex becomes unlocked, then exactly one of those threads will get the lock on the mutex and return control to the caller (the other blocking threads will continue to block and wait for their turn).
See [PKCS11-BASE] Section 5.1.5 for more information on Cryptoki’s view of mutex objects.
In addition to providing the above thread-handling information to a Cryptoki library at initialization time, an application can also specify whether or not application threads executing library calls may use native operating system calls to spawn new threads.
Cryptoki requires that an application open one or more sessions with a token to gain access to the token’s objects and functions. A session provides a logical connection between the application and the token. A session can be a read/write (R/W) session or a read-only (R/O) session. Read/write and read-only refer to the access to token objects, not to session objects. In both session types, an application can create, read, write and destroy session objects, and read token objects. However, only in a read/write session can an application create, modify, and destroy token objects.
After it opens a session, an application has access to the token’s public objects. All threads of a given application have access to exactly the same sessions and the same session objects. To gain access to the token’s private objects, the normal user must log in and be authenticated.
When a session is closed, any session objects which were created in that session are destroyed. This holds even for session objects that are “being used” by other sessions. That is, if a single application has multiple sessions open with a token, and it uses one of them to create a session object, then that session object is visible through any of that application’s sessions. However, as soon as the session that was used to create the object is closed, that object is destroyed.
Cryptoki supports multiple sessions on multiple tokens. An application may have one or more sessions with one or more tokens. In general, a token may have multiple sessions with one or more applications. A particular token may allow an application to have only a limited number of sessions—or only a limited number of read/write sessions-- however.
An open session can be in one of several states. The session state determines allowable access to objects and functions that can be performed on them. The session states are described in Section 2 and Section 3.
A read-only session can be in one of two states, as illustrated in the following figure. When the session is initially opened, it is in either the “R/O Public Session” state (if the application has no previously open sessions that are logged in) or the “R/O User Functions” state (if the application already has an open session that is logged in). Note that read-only SO sessions do not exist. Read-only sessions that are open while the SO is logged in behave identically to the "R/O Public Session" state.
Figure 3: Read-Only Session States
The following table describes the session states:
Table 1: Read-Only Session States
|
State |
Description |
|
R/O Public Session |
The application has opened a read-only session. The application has read-only access to public token objects and read/write access to public session objects. |
|
R/O User Functions |
The normal user has been authenticated to the token. The application has read-only access to all token objects (public or private) and read/write access to all session objects (public or private). |
A read/write session can be in one of three states, as illustrated in the following figure. When the session is opened, it is in either the “R/W Public Session” state (if the application has no previously open sessions that are logged in), the “R/W User Functions” state (if the application already has an open session that the normal user is logged into), or the “R/W SO Functions” state (if the application already has an open session that the SO is logged into).
Figure 4: Read/Write Session States
The following table describes the session states:
Table 2: Read/Write Session States
|
State |
Description |
|
R/W Public Session |
The application has opened a read/write session. The application has read/write access to all public objects. |
|
R/W SO Functions |
The Security Officer has been authenticated to the token. The application has read/write access only to public objects on the token, not to private objects. The SO can set the normal user’s PIN. |
|
R/W User Functions |
The normal user has been authenticated to the token. The application has read/write access to all objects. |
The following table summarizes the kind of access each type of session has to each type of object. A given type of session has either read-only access, read/write access, or no access whatsoever to a given type of object.
Note that creating or deleting an object requires read/write access to it, e.g., a “R/O User Functions” session cannot create or delete a token object.
Table 3: Access to Different Types Objects by Different Types of Sessions
|
|
Type of session |
||||
|
Type of object |
R/O Public |
R/W Public |
R/O User |
R/W User |
R/W SO |
|
Public session object |
R/W |
R/W |
R/W |
R/W |
R/W |
|
Private session object |
|
|
R/W |
R/W |
|
|
Public token object |
R/O |
R/W |
R/O |
R/W |
R/W |
|
Private token object |
|
|
R/O |
R/W |
|
As previously indicated, the access to a given session object which is shown in Table is limited to sessions belonging to the application which owns that object (i.e., which created that object).
Session events cause the session state to change. The following table describes the events:
|
Event |
Occurs when... |
|
Log In SO |
the SO is authenticated to the token. |
|
Log In User |
the normal user is authenticated to the token. |
|
Log Out |
the application logs out the current user (SO or normal user). |
|
Close Session |
the application closes the session or closes all sessions. |
|
Device Removed |
the device underlying the token has been removed from its slot. |
When the device is removed, all sessions of all applications are automatically logged out. Furthermore, all sessions any applications have with the device are closed (this latter behavior was not present in Version 1.0 of Cryptoki)—an application cannot have a session with a token that is not present. Realistically, Cryptoki may not be constantly monitoring whether or not the token is present, and so the token’s absence could conceivably not be noticed until a Cryptoki function is executed. If the token is re-inserted into the slot before that, Cryptoki might never know that it was missing.
In Cryptoki, all sessions that an application has with a token must have the same login/logout status (i.e., for a given application and token, one of the following holds: all sessions are public sessions; all sessions are SO sessions; or all sessions are user sessions). When an application’s session logs into a token, all of that application’s sessions with that token become logged in, and when an application’s session logs out of a token, all of that application’s sessions with that token become logged out. Similarly, for example, if an application already has a R/O user session open with a token, and then opens a R/W session with that token, the R/W session is automatically logged in.
This implies that a given application may not simultaneously have SO sessions and user sessions open with a given token.
A session handle is a Cryptoki-assigned value that identifies a session. It is in many ways akin to a file handle, and is specified to functions to indicate which session the function should act on. All threads of an application have equal access to all session handles. That is, anything that can be accomplished with a given file handle by one thread can also be accomplished with that file handle by any other thread of the same application.
Cryptoki also has object handles, which are identifiers used to manipulate Cryptoki objects. Object handles are similar to session handles in the sense that visibility of a given object through an object handle is the same among all threads of a given application. R/O sessions, of course, only have read-only access to token objects, whereas R/W sessions have read/write access to token objects.
Valid session handles and object handles in Cryptoki always have nonzero values. For developers’ convenience, Cryptoki defines the following symbolic value:
CK_INVALID_HANDLE
Very roughly speaking, there are three broad types of operations an open session can be used to perform: administrative operations (such as logging in); object management operations (such as creating or destroying an object on the token); and cryptographic operations (such as computing a message digest). Cryptographic operations sometimes require more than one function call to the Cryptoki API to complete. In general, a single session can perform only one operation at a time; for this reason, it may be desirable for a single application to open multiple sessions with a single token. For efficiency’s sake, however, a single session on some tokens can perform the following pairs of operation types simultaneously: message digesting and encryption; decryption and message digesting; signature or MACing and encryption; and decryption and verifying signatures or MACs. Details on performing simultaneous cryptographic operations in one session are provided in [PKCS11-Base] Section 5.12.
A consequence of the fact that a single session can, in general, perform only one operation at a time is that an application should never make multiple simultaneous function calls to Cryptoki which use a common session. If multiple threads of an application attempt to use a common session concurrently in this fashion, Cryptoki does not define what happens. This means that if multiple threads of an application all need to use Cryptoki to access a particular token, it might be appropriate for each thread to have its own session with the token, unless the application can ensure by some other means (e.g., by some locking mechanism) that no sessions are ever used by multiple threads simultaneously. This is true regardless of whether or not the Cryptoki library was initialized in a fashion which permits safe multi-threaded access to it. Even if it is safe to access the library from multiple threads simultaneously, it is still not necessarily safe to use a particular session from multiple threads simultaneously.
We give here a detailed and lengthy example of how multiple applications can make use of sessions in a Cryptoki library. Despite the somewhat painful level of detail, we highly recommend reading through this example carefully to understand session handles and object handles.
We caution that our example is decidedly not meant to indicate how multiple applications should use Cryptoki simultaneously; rather, it is meant to clarify what uses of Cryptoki’s sessions and objects and handles are permissible. In other words, instead of demonstrating good technique here, we demonstrate “pushing the envelope”.
For our example, we suppose that two applications, A and B, are using a Cryptoki library to access a single token T. Each application has two threads running: A has threads A1 and A2, and B has threads B1 and B2. We assume in what follows that there are no instances where multiple threads of a single application simultaneously use the same session, and that the events of our example occur in the order specified, without overlapping each other in time.
1. A1 and B1 each initialize the Cryptoki library by calling C_Initialize (see [PKCS11-Base] for explanation of the specifics of Cryptoki functions). Note that exactly one call to C_Initialize should be made for each application (as opposed to one call for every thread, for example).
2. A1 opens a R/W session and receives the session handle 7 for the session. Since this is the first session to be opened for A, it is a public session.
3. A2 opens a R/O session and receives the session handle 4. Since all of A’s existing sessions are public sessions, session 4 is also a public session.
4. A1 attempts to log the SO into session 7. The attempt fails, because read-only sessions cannot be used to log in the SO.
5. A2 logs the normal user into session 7. This turns session 7 into a R/W user session, and turns session 4 into a R/O user session. Note that because A1 and A2 belong to the same application, they have equal access to all sessions, and therefore, A2 is able to perform this action.
6. A2 opens a R/W session and receives the session handle 9. Since all of A’s existing sessions are user sessions, session 9 is also a user session.
7. A1 closes session 9.
8. B1 attempts to log out session 4. The attempt fails, because A and B have no access rights to each other’s sessions or objects. B1 receives an error message which indicates that there is no such session handle (CKR_SESSION_HANDLE_INVALID).
9. B2 attempts to close session 4. The attempt fails in precisely the same way as B1’s attempt to log out session 4 failed (i.e., B2 receives a CKR_SESSION_HANDLE_INVALID error code).
10. B1 opens a R/W session and receives the session handle 7. Note that, as far as B is concerned, this is the first occurrence of session handle 7. A’s session 7 and B’s session 7 are completely different sessions.
11. B1 logs the SO into [B’s] session 7. This turns B’s session 7 into a R/W SO session, and has no effect on either of A’s sessions.
12. A1 uses [A’s] session 7 to create a session object O1 of some sort and receives the object handle 7. Note that a Cryptoki implementation may or may not support separate spaces of handles for sessions and objects.
13. B1 uses [B’s] session 7 to create a token object O2 of some sort and receives the object handle 7. As with session handles, different applications have no access rights to each other’s object handles, and so B’s object handle 7 is entirely different from A’s object handle 7. Of course, since B1 is an SO session, it cannot create private objects, and so O2 must be a public object (if B1 attempted to create a private object, the attempt would fail with error code CKR_USER_NOT_LOGGED_IN or CKR_TEMPLATE_INCONSISTENT).
14. B2 uses [B’s] session 7 to perform some operation to modify the object associated with [B’s] object handle 7. This modifies O2.
15. A1 uses [A’s] session 4 to perform an object search operation to get a handle for O2. The search returns object handle 1. Note that A’s object handle 1 and B’s object handle 7 now point to the same object.
16. A1 attempts to use [A’s] session 4 to modify the object associated with [A’s] object handle 1. The attempt fails, because A’s session 4 is a R/O session, and is therefore incapable of modifying O2, which is a token object. A1 receives an error message indicating that the session is a R/O session (CKR_SESSION_READ_ONLY).
17. A1 uses [A’s] session 7 to modify the object associated with [A’s] object handle 1. This time, since A’s session 7 is a R/W session, the attempt succeeds in modifying O2.
18. B1 uses [B’s] session 7 to perform an object search operation to find O1. Since O1 is a session object belonging to A, however, the search does not succeed.
19. A2 uses [A’s] session 4 to perform some operation to modify the object associated with [A’s] object handle 7. This operation modifies O1.
20. A2 uses [A’s] session 7 to destroy the object associated with [A’s] object handle 1. This destroys O2.
21. B1 attempts to perform some operation with the object associated with [B’s] object handle 7. The attempt fails, since there is no longer any such object. B1 receives an error message indicating that its object handle is invalid (CKR_OBJECT_HANDLE_INVALID).
22. A1 logs out [A’s] session 4. This turns A’s session 4 into a R/O public session, and turns A’s session 7 into a R/W public session.
23. A1 closes [A’s] session 7. This destroys the session object O1, which was created by A’s session 7.
24. A2 attempt to use [A’s] session 4 to perform some operation with the object associated with [A’s] object handle 7. The attempt fails, since there is no longer any such object. It returns a CKR_OBJECT_HANDLE_INVALID.
25. A2 executes a call to C_CloseAllSessions. This closes [A’s] session 4. At this point, if A were to open a new session, the session would not be logged in (i.e., it would be a public session).
26. B2 closes [B’s] session 7. At this point, if B were to open a new session, the session would not be logged in.
27. A and B each call C_Finalize to indicate that they are done with the Cryptoki library.
Modules implementing previous versions of PKCS #11 may return the CKR_SESSION_READ_ONLY_EXISTS and CKR_SESSION_READ_WRITE_SO_EXISTS error codes.
3 Security considerations
As an interface to cryptographic devices, Cryptoki provides a basis for security in a computer or communications system. Two of the particular features of the interface that facilitate such security are the following:
1. Access to private objects on the token, and possibly to cryptographic functions and/or certificates on the token as well, requires a PIN. Thus, possessing the cryptographic device that implements the token may not be sufficient to use it; the PIN may also be needed.
2. Additional protection can be given to private keys and secret keys by marking them as “sensitive” or “unextractable”. Sensitive keys cannot be revealed in plaintext off the token, and unextractable keys cannot be revealed off the token even when encrypted (though they can still be used as keys).
It is expected that access to private, sensitive, or unextractable objects by means other than Cryptoki (e.g., other programming interfaces, or reverse engineering of the device) would be difficult.
If a device does not have a tamper-proof environment or protected memory in which to store private and sensitive objects, the device may encrypt the objects with a master key which is perhaps derived from the user’s PIN. The particular mechanism for protecting private objects is left to the device implementation, however.
Based on these features it should be possible to design applications in such a way that the token can provide adequate security for the objects the applications manage.
Of course, cryptography is only one element of security, and the token is only one component in a system. While the token itself may be secure, one must also consider the security of the operating system by which the application interfaces to it, especially since the PIN may be passed through the operating system. This can make it easy for a rogue application on the operating system to obtain the PIN; it is also possible that other devices monitoring communication lines to the cryptographic device can obtain the PIN. Rogue applications and devices may also change the commands sent to the cryptographic device to obtain services other than what the application requested.
It is important to be sure that the system is secure against such attack. Cryptoki may well play a role here; for instance, a token may be involved in the “booting up” of the system.
We note that none of the attacks just described can compromise keys marked “sensitive,” since a key that is sensitive will always remain sensitive. Similarly, a key that is unextractable cannot be modified to be extractable.
An application may also want to be sure that the token is “legitimate” in some sense (for a variety of reasons, including export restrictions and basic security). This is outside the scope of the present standard, but it can be achieved by distributing the token with a built-in, certified public/private-key pair, by which the token can prove its identity. The certificate would be signed by an authority (presumably the one indicating that the token is “legitimate”) whose public key is known to the application. The application would verify the certificate and challenge the token to prove its identity by signing a time-varying message with its built-in private key.
Once a normal user has been authenticated to the token, Cryptoki does not restrict which cryptographic operations the user may perform; the user may perform any operation supported by the token. Some tokens may not even require any type of authentication to make use of its cryptographic functions.
To protect against chosen ciphertext attacks, like the Bleichenbacher attack, use PKCS #1 Version 2, with OAEP, and disable support for PKCS #1, Version 1.5..
Furthermore, more specifically to smart card implementations, the requirement of the PIN and a long open connection to the device is required to execute the attack. For smartcard implementations, execution of these attacks requires private key operations and a sufficiently long open connection. It is strongly recommended that any applets exposing private key operations are protected using an encrypted PIN (a PIN not submitted in the clear), and the session is closed when not in use.
In Cryptoki, there are several different types of operations which can be “active” in a session. An active operation is essentially one which takes more than one Cryptoki function call to perform. The types of active operations are object searching; encryption; decryption; message-digesting; signature with appendix; signature with recovery; verification with appendix; and verification with recovery.
A given session can have 0, 1, or 2 operations active at a time. It can only have 2 operations active simultaneously if the token supports this; moreover, those two operations must be one of the four following pairs of operations: digesting and encryption; decryption and digesting; signing and encryption; decryption and verification.
If an application attempts to initialize an operation (make it active) in a session, but this cannot be accomplished because of some other active operation(s), the application receives the error value CKR_OPERATION_ACTIVE. This error value can also be received if a session has an active operation and the application attempts to use that session to perform any of various operations which do not become “active”, but which require cryptographic processing, such as using the token’s random number generator, or generating/wrapping/unwrapping/deriving a key.
To abandon an active operation an application may have to complete the operation and discard the result. Closing the session will also have this effect. Alternatively, the library may allow active operations to be abandoned by the application, simply by allowing initialization for some other operation. In this case CKR_OPERATION_ACTIVE will not be returned but the previous active operation will be unusable.
Different threads of an application should never share sessions, unless they are extremely careful not to make function calls at the same time. This is true even if the Cryptoki library was initialized with locking enabled for thread-safety.
When multiple applications, or multiple threads within an application, are accessing a set of common objects the issue of object protection becomes important. This is especially the case when application A activates an operation using object O, and application B attempts to delete O before application A has finished the operation. Unfortunately, variation in device capabilities makes an absolute behavior specification impractical. General guidelines are presented here for object protection behavior.
Whenever possible, deleting an object in one application should not cause that object to become unavailable to another application or thread that is using the object in an active operation until that operation is complete. For instance, application A has begun a signature operation with private key P and application B attempts to delete P while the signature is in progress. In this case, one of two things should happen. The object is deleted from the device but the operation is allow to complete because the operation uses a temporary copy of the object, or the delete operation blocks until the signature operation has completed. If neither of these actions can be supported by an implementation, then the error code CKR_OBJECT_HANDLE_INVALID may be returned to application A to indicate that the key being used to perform its active operation has been deleted.
Whenever possible, changing the value of an object attribute should impact the behavior of active operations in other applications or threads. If this cannot be supported by an implementation, then the appropriate error code indicating the reason for the failure should be returned to the application with the active operation.
In general, a Cryptoki function which requires a template for an object needs the template to specify—either explicitly or implicitly—any attributes that are not specified elsewhere. If a template specifies a particular attribute more than once, the function can return CKR_TEMPLATE_INVALID or it can choose a particular value of the attribute from among those specified and use that value. In any event, object attributes are always single-valued.
Signing with recovery is a general alternative to ordinary digital signatures (“signing with appendix”) which is supported by certain mechanisms. Recall that for ordinary digital signatures, a signature of a message is computed as some function of the message and the signer’s private key; this signature can then be used (together with the message and the signer’s public key) as input to the verification process, which yields a simple “signature valid/signature invalid” decision.
Signing with recovery also creates a signature from a message and the signer’s private key. However, to verify this signature, no message is required as input. Only the signature and the signer’s public key are input to the verification process, and the verification process outputs either “signature invalid” or—if the signature is valid—the original message.
Consider a simple example with the CKM_RSA_X_509 mechanism. Here, a message is a byte string which we will consider to be a number modulo n (the signer’s RSA modulus). When this mechanism is used for ordinary digital signatures (signatures with appendix), a signature is computed by raising the message to the signer’s private exponent modulo n. To verify this signature, a verifier raises the signature to the signer’s public exponent modulo n, and accepts the signature as valid if and only if the result matches the original message.
If CKM_RSA_X_509 is used to create signatures with recovery, the signatures are produced in exactly the same fashion. For this particular mechanism, any number modulo n is a valid signature. To recover the message from a signature, the signature is raised to the signer’s public exponent modulo n.
The following table lists the FORTEZZA CIPG functions, together with the equivalent Cryptoki functions. See [FORTEZZA] for more information on the FORTEZZA API.
Table 5: FORTEZZA CIPG vs. Cryptoki
|
FORTEZZA CIPG |
Equivalent Cryptoki |
|
CI_ChangePIN |
C_InitPIN, C_SetPIN |
|
CI_CheckPIN |
C_Login |
|
CI_Close |
C_CloseSession |
|
CI_Decrypt |
C_DecryptInit, C_Decrypt, C_DecryptUpdate, C_DecryptFinal |
|
CI_DeleteCertificate |
C_DestroyObject |
|
CI_DeleteKey |
C_DestroyObject |
|
CI_Encrypt |
C_EncryptInit, C_Encrypt, C_EncryptUpdate, C_EncryptFinal |
|
CI_ExtractX |
C_WrapKey |
|
CI_GenerateIV |
C_GenerateRandom |
|
CI_GenerateMEK |
C_GenerateKey |
|
CI_GenerateRa |
C_GenerateRandom |
|
CI_GenerateRandom |
C_GenerateRandom |
|
CI_GenerateTEK |
C_GenerateKey |
|
CI_GenerateX |
C_GenerateKeyPair |
|
CI_GetCertificate |
C_FindObjects |
|
CI_Configuration |
C_GetTokenInfo |
|
CI_GetHash |
C_DigestInit, C_Digest, C_DigestUpdate, and C_DigestFinal |
|
CI_GetIV |
No equivalent |
|
CI_GetPersonalityList |
C_FindObjects |
|
CI_GetState |
C_GetSessionInfo |
|
CI_GetStatus |
C_GetTokenInfo |
|
CI_GetTime |
C_GetTokenInfo or C_GetAttributeValue(clock object) [preferred] |
|
CI_Hash |
C_DigestInit, C_Digest, C_DigestUpdate, and C_DigestFinal |
|
CI_Initialize |
C_Initialize |
|
CI_InitializeHash |
C_DigestInit |
|
CI_InstallX |
C_UnwrapKey |
|
CI_LoadCertificate |
C_CreateObject |
|
CI_LoadDSAParameters |
C_CreateObject |
|
CI_LoadInitValues |
C_SeedRandom |
|
CI_LoadIV |
C_EncryptInit, C_DecryptInit |
|
CI_LoadK |
C_SignInit |
|
CI_LoadPublicKeyParameters |
C_CreateObject |
|
CI_LoadPIN |
C_SetPIN |
|
CI_LoadX |
C_CreateObject |
|
CI_Lock |
Implicit in session management |
|
CI_Open |
C_OpenSession |
|
CI_RelayX |
C_WrapKey |
|
CI_Reset |
C_CloseAllSessions |
|
CI_Restore |
Implicit in session management |
|
CI_Save |
Implicit in session management |
|
CI_Select |
C_OpenSession |
|
CI_SetConfiguration |
No equivalent |
|
CI_SetKey |
C_EncryptInit, C_DecryptInit |
|
CI_SetMode |
C_EncryptInit, C_DecryptInit |
|
CI_SetPersonality |
C_CreateObject |
|
CI_SetTime |
No equivalent |
|
CI_Sign |
C_SignInit, C_Sign |
|
CI_Terminate |
C_CloseAllSessions |
|
CI_Timestamp |
C_SignInit, C_Sign |
|
CI_Unlock |
Implicit in session management |
|
CI_UnwrapKey |
C_UnwrapKey |
|
CI_VerifySignature |
C_VerifyInit, C_Verify |
|
CI_VerifyTimestamp |
C_VerifyInit, C_Verify |
|
CI_WrapKey |
C_WrapKey |
|
CI_Zeroize |
C_InitToken |
This proposed standard defines an API to high-level security services such as authentication of identities and data-origin, non-repudiation, and separation and protection. It is at a higher level than Cryptoki. The following table lists the GCS-API functions with the Cryptoki functions used to implement the functions. Note that full support of GCS-API is left for future versions of Cryptoki. See [GCS-API] for more information on the API.
Table 6: GCS-API vs. Cryptoki
|
GCS-API |
Cryptoki implementation |
|
retrieve_CC |
|
|
release_CC |
|
|
generate_hash |
C_DigestInit, C_Digest |
|
generate_random_number |
C_GenerateRandom |
|
generate_checkvalue |
C_SignInit, C_Sign, C_SignUpdate, C_SignFinal |
|
verify_checkvalue |
C_VerifyInit, C_Verify, C_VerifyUpdate, C_VerifyFinal |
|
data_encipher |
C_EncryptInit, C_Encrypt, C_EncryptUpdate, C_EncryptFinal |
|
data_decipher |
C_DecryptInit, C_Decrypt, C_DecryptUpdate, C_DecryptFinal |
|
create_CC |
|
|
derive_key |
C_DeriveKey |
|
generate_key |
C_GenerateKey |
|
store_CC |
|
|
delete_CC |
|
|
replicate_CC |
|
|
export_key |
C_WrapKey |
|
import_key |
C_UnwrapKey |
|
archive_CC |
C_WrapKey |
|
restore_CC |
C_UnwrapKey |
|
set_key_state |
|
|
generate_key_pattern |
|
|
verify_key_pattern |
|
|
derive_clear_key |
C_DeriveKey |
|
generate_clear_key |
C_GenerateKey |
|
load_key_parts |
|
|
clear_key_encipher |
C_WrapKey |
|
clear_key_decipher |
C_UnwrapKey |
|
change_key_context |
|
|
load_initial_key |
|
|
generate_initial_key |
|
|
set_current_master_key |
|
|
protnder_new_master_key |
|
|
proect_under_current_master_key |
|
|
initialise_random_number_generator |
C_SeedRandom |
|
install_algorithm |
|
|
de_install_algorithm |
|
|
disable_algorithm |
|
|
enable_algorithm |
|
|
set_defaults |
|
Note: This support may be present for backwards compatibility. Refer to [PKCS#11- 2.1]1 for details.
Note: This support may be present for backwards compatibility. Refer to [PKCS11-V 2.11] for details.
This section describes sample “profiles,” i.e., sets of mechanisms, which a token should support for various common types of application that were defined in PKCS #11 V2.30. It is expected that these sets would be standardized as parts of the various applications, for instance within a list of requirements on the module that provides cryptographic services to the application (which may be a Cryptoki token in some cases). Thus, these profiles are intended for reference only at this point, and are not part of this standard.
The following table summarizes the mechanisms relevant to two common types of applications:
Table 7: Mechanisms and profiles
|
|
Application |
|
|
Mechanism |
Government Authentication-only |
Cellular Digital Packet Data |
|
CKM_DSA_KEY_PAIR_GEN |
ü |
|
|
CKM_DSA |
ü |
|
|
CKM_DH_PKCS_KEY_PAIR_GEN |
|
ü |
|
CKM_DH_PKCS_DERIVE |
|
ü |
|
CKM_RC4_KEY_GEN |
|
ü |
|
CKM_RC4 |
|
ü |
|
CKM_SHA_1 |
ü |
|
The U.S. government has standardized on the Digital Signature Algorithm as defined in FIPS PUB 186-2 for signatures and the Secure Hash Algorithm as defined in FIPS PUB 180-2 for message digesting. The relevant mechanisms include the following:
DSA key generation (512-1024 bits)
DSA (512-1024 bits)
SHA-1
Cellular Digital Packet Data (CDPD) is a set of protocols for wireless communication. The basic set of mechanisms to support CDPD applications includes the following:
Diffie-Hellman key generation (256-1024 bits)
Diffie-Hellman key derivation (256-1024 bits)
RC4 key generation (40-128 bits)
RC4 (40-128 bits)
(The initial CDPD security specification limits the size of the Diffie-Hellman key to 256 bits, but it has been recommended that the size be increased to at least 512 bits.)
The reader is also informed of the presence of other sample profiles defined prior to PKCS #11 v2.40. See the documentation for previous versions of PKCS #11.
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
Participants:
Gil Abel, Athena Smartcard Solutions, Inc.
Warren Armstrong, QuintessenceLabs
Jeff Bartell, Semper Foris Solutions LLC
Peter Bartok, Venafi, Inc.
Anthony Berglas, Cryptsoft
Joseph Brand, Semper Fortis Solutions LLC
Kelley Burgin, National Security Agency
Robert Burns, Thales e-Security
Wan-Teh Chang, Google Inc.
Hai-May Chao, Oracle
Janice Cheng, Vormetric, Inc.
Sangrae Cho, Electronics and Telecommunications Research Institute (ETRI)
Doron Cohen, SafeNet, Inc.
Fadi Cotran, Futurex
Tony Cox, Cryptsoft
Christopher Duane, EMC
Chris Dunn, SafeNet, Inc.
Valerie Fenwick, Oracle
Terry Fletcher, SafeNet, Inc.
Susan Gleeson, Oracle
Sven Gossel, Charismathics
John Green, QuintessenceLabs
Robert Griffin, EMC
Paul Grojean, Individual
Peter Gutmann, Individual
Dennis E. Hamilton, Individual
Thomas Hardjono, M.I.T.
Tim Hudson, Cryptsoft
Gershon Janssen, Individual
Seunghun Jin, Electronics and Telecommunications Research Institute (ETRI)
Wang Jingman, Feitan Technologies
Andrey Jivsov, Symantec Corp.
Mark Joseph, P6R
Stefan Kaesar, Infineon Technologies
Greg Kazmierczak, Wave Systems Corp.
Mark Knight, Thales e-Security
Darren Krahn, Google Inc.
Alex Krasnov, Infineon Technologies AG
Dina Kurktchi-Nimeh, Oracle
Mark Lambiase, SecureAuth Corporation
Lawrence Lee, GoTrust Technology Inc.
John Leiseboer, QuintessenceLabs
Sean Leon, Infineon Technologies
Geoffrey Li, Infineon Technologies
Howie Liu, Infineon Technologies
Hal Lockhart, Oracle
Robert Lockhart, Thales e-Security
Dale Moberg, Axway Software
Darren Moffat, Oracle
Valery Osheter, SafeNet, Inc.
Sean Parkinson, EMC
Rob Philpott, EMC
Mark Powers, Oracle
Ajai Puri, SafeNet, Inc.
Robert Relyea, Red Hat
Saikat Saha, Oracle
Subhash Sankuratripati, NetApp
Anthony Scarpino, Oracle
Johann Schoetz, Infineon Technologies AG
Rayees Shamsuddin, Wave Systems Corp.
Radhika Siravara, Oracle
Brian Smith, Mozilla Corporation
David Smith, Venafi, Inc.
Ryan Smith, Futurex
Jerry Smith, US Department of Defense (DoD)
Oscar So, Oracle
Graham Steel, Cryptosense
Michael Stevens, QuintessenceLabs
Michael StJohns, Individual
Jim Susoy, P6R
Sander Temme, Thales e-Security
Kiran Thota, VMware, Inc.
Walter-John Turnes, Gemini Security Solutions, Inc.
Stef Walter, Red Hat
James Wang, Vormetric
Jeff Webb, Dell
Peng Yu, Feitian Technologies
Magda Zdunkiewicz, Cryptsoft
Chris Zimman, Individual
|
Revision |
Date |
Editor |
Changes Made |
|
wd01 |
18 March 2013 |
John Leiseboer |
Initial version |
|
wd02 |
10 June 2013 |
John Leiseboer |
Incorporated usage information from PCKS #11 Base Specification V2.30 |
|
wd03 |
10 September 2013 |
Robert Griffin |
Incorporated new sections from approved ballots |
|
wd04 |
16 September 2013 |
Robert Griffin |
Updated participants list |
|
wd05 |
1 October 2013 |
Robert Griffin |
Removed design goals section as discussed in face-to-face meeting. |
|
wd06 |
27 October 2013 |
John Leiseboer / Robert Griffin |
Final participant list and other editorial changes for Committee Note Draft |
|
cnd01 |
30 October 2013 |
OASIS |
Committee Note Draft |
|
wd07 |
15 February 2014 |
Robert Griffin |
Corrections and changes from public review |
|
cnd02 |
23 April 2014 |
OASIS |
Committee Note Draft |
|
cnd02a |
Sep 3 2014 |
John Leiseboer / Robert Griffin |
Updated revision history and participant list in preparation for Committee Specification ballot |
|
wd08 |
3 November 2014 |
Robert Griffin |
Editorial corrections |


Sample:
NAT13
NAT12
NAT11
Category:
CODING
INVALID
MISSING
SIGNCRED
Method:
SUM
AVG
Y Axis:
NET PAYMENT ERROR
GROSS PAYMENT ERROR
Order:
Ascending
Descending
Sort By:
Key


We are a small IT company based in Villemomble, France. Misoda population until now {{ today | date: 'mediumDate' }} is quite few in number but very high in quality. Selection is taken cared of since the beginning from the first interview. Only individuals with highly motivated, open mindset, teamwork and beautiful personality are chosen. In Misoda, we do our job with love first, then for the money. Contact us by mail for more info. In the mean time, feel free to checkout our work in this website. Good day.


Congrats, you've successfully integrated your {{ integration.type | integrationType }} with MIMO!
Here's what we've done for you:
We've updated the settings for you chosen SSID so it will work with the MIMO splash pages.
It's really important you complete the setup guide and enable the splash page. If you don't do this, the splash pages won't work.
Here's what we've done:
We've updated the settings for you chosen SSID so it will work with the MIMO splash pages.
Here's what we've done:
It can take a few minutes for your {{ integration.type | integrationType }} to sync all the settings. Once you see '{{integration.ssid}}' in your list of available networks, connect to it. You should be redirected to a splash page immediately.
You'll find your splash password in your splash page settings within MIMO.
If you can't see the network, please check your {{ integration.type | integrationType }}'s settings (and be patient)!
Once you've completed the setup, connect to your guest SSID. You should be automatically directed.
You'll find your splash password in your splash page settings within MIMO.
While you're waiting, why not customise your splash page?


Algorithm Study Site
Home
(current)
Notes
Add Notes
Algorithms
Add algorithm
Search
New Algorithm
Name
Algorithm class
Strategy
Brute force
Divide and conquer
Decrease and conquer
Greedy
Dynamic programming
Other
Worst case asymptotic complexity
O(1)
O(log(log(n)))
O(log(n))
O(nlog(n))
O((n^2)log(n))
O(n)
O(n + k)
O(nk)
O(n^2)
O(n^3)
Other (Specify below)
Average case asymptotic complexity
O(1)
O(log(log(n)))
O(log(n))
O(nlog(n))
O((n^2)log(n))
O(n)
O(n + k)
O(nk)
O(n^2)
O(n^3)
Other (Specify below)
Best case asymptotic complexity
O(1)
O(log(log(n)))
O(log(n))
O(nlog(n))
O((n^2)log(n))
O(n)
O(n + k)
O(nk)
O(n^2)
O(n^3)
Other (Specify below)
Algorithm pseudocode
Extra facts?
Add algorithm
Delete algorithm


Strapboot
name
homepage
local
description
version
author
copyright
repository
taskrunner
gulp
grunt
styles
css
scss
scripts
webpack
concat
download


My Books
Authors
Books
Add
Enter a 10 or 13 digit ISBN and check to see if this book is already listed.
ISBN
Title
Author Last Name
Author First Name
Classification
Science Fiction
Fantasy
Fiction
Non-Fiction
Textbook
Rating
Year of First Publication
Year of My Edition


Vic hospitals plunged into crisis as population growth overruns Budget
by Unconventional EconomistIn the 14 years to June 2018, Melbourne’s population ballooned by 1,320,000 or 36%, with an average of 94,000 people flooding into the city each and every year, driven mostly via immigration:
And over the next 48 years, Melbourne’s population is projected by the ABS to more than double to 10.2 million people, growing at an even faster pace of 109,000 per year:
There are 1213 words left in this subscriber-only article.


IDMA Winners 2018
| A.WEB WINNER | ||||
| A.1 Best Banners -Single/ Campaign | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Project Avalanche – $43 billion corporation on a Single Canvas | Mindshare India | Aditya Birla Group | Bronze |
| A2. Best Banners - Rich Media with or without Video | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Amazon Fire TV Launch | Interactive Avenues | Amazon Seller Services | Bronze |
| 2 | Royale Atmos - The Week We Unmasked India | Madison Media | Asian Paints | Gold |
| A3 Best Benchmark Content/ Branded Content | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Mahindra tractors #SowTheFuture: Empowering the Second-Generation Farmer | Interactive Avenues | Mahindra & Mahindra | Bronze |
| 2 | Kissan Tiffin Time Table - Har Din Naya Tiffin, Har Din Empty Tiffin! | Mindshare India | Hindustan Unilever Ltd | Silver |
| 3 | #JumpForhealth | Aditya Birla Captial's Health Insurance part of Aditya Birla Group | Silver |
|
| A4. Best Website/ Microsite | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Star Sports - Pro Kabaddi website | Sportz Interactive | Star India Pvt Ltd | Bronze |
| 2 | Rakhi with Fabelle | Madison Media | ITC Ltd | Silver |
| 3 | Zee TV - #ChangeHerNot for Kaleerein | Zee Entertainment Enterprises Ltd | Gold |
|
| A.5 Best Use of Web Based Games | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Star Sports - Khel Kabaddi | Sportz Interactive | Star India Pvt Ltd | Bronze |
| 2 | Mahindra Tractors - Turning playtime into learning for the second-gen farmer | Interactive Avenues | Mahindra & Mahindra | Bronze |
| 3 | Jio - 30 Million touches | Vibrant Advertising | Reliance Jio Infocomm | Silver |
| A6. Best Campaign- Online Advertising | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | 30 Million touches | Vibrant Advertising | Reliance Jio Infocomm | Bronze |
| 2 | #JumpForhealth | Mindshare India | Aditya Birla Captial's Health Insurance part of Aditya Birla Group | Silver |
| 3 | Big Bazaar Sabse Saste 5 Din : India's first 24 hour Facebook Live | Law & Kenneth Saatchi & Saatchi | Future Group | Silver |
| 4 | Kissan Tiffin Time Table - Har Din Naya Tiffin, Har Din Empty Tiffin! | Mindshare India | Hindustan Unilever Ltd | Silver |
| B. MOBILE & TABLETS WINNER | ||||
| B1. Best Use of WAP /Html/ other sites for Mobiles | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Rakhi with Fabelle | Madison Media | ITC Ltd | Bronze |
| 2 | Godrej HIT - Track The Bite | InteractionOne Solutions | Godrej Consumer Products Ltd | Bronze |
| 3 | Zee TV - #ChangeHerNot for Kaleerein | Zee Entertainment Enterprises Ltd | Silver |
|
| B2. Best App Developed- Products / Services / Corporate / Social/ Films / TV Shows / Entertainment/ Lifestyle / Gaming etc. | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Jio - 30 Million touches | Vibrant Advertising | Reliance Jio Infocomm | Bronze |
| 2 | Pitchers App | 22 Feet Tribal Worldwide | United Breweries Ltd | Silver |
| 3 | Godrej HIT | InteractionOne Solutions | Godrej Consumer Products Ltd | Gold |
| B3. Best Innovation in Mobile Marketing | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | When Tinder Swiped Right for Nike | Mindshare India | NIKE | Bronze |
| 2 | The car that took the Internet for a ride | The 120 Media Collective | TATA Motors | Silver |
| B4. Best Campaign- Use of Mobile | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | McDowells no.1 Soda - Friendship:1 Drunk Driving-0 | Mindshare India | Diageo India | Bronze |
| 2 | McDowell's No 1 #Jointhepact | InMobi | Diageo India | Silver |
| C. SOCIAL MEDIA WINNER | ||||
| C1. Best Use of Social Networks | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Zee TV #ChangeHerNot for Kaleerein | Zee Entertainment Enterprises Ltd | Silver |
|
| 2 | REDFM - Mumbai Khadde Mein | Digital Radio Delhi Broadcasting Ltd | Silver |
|
| 3 | TED Talks India Nayi Soch | Star Plus | Star India Pvt Ltd | Silver |
| 4 | #WantedFairBridesAndGrooms | Shaadi.com | Gold |
|
| 5 | #JumpForhealth | Mindshare India | Aditya Birla Captial's Health Insurance part of Aditya Birla Group | Gold |
| 6 | ActivKids Immuno Booster - Yes Mom | Msix | Cipla Health Ltd. | Bronze |
| C2. Best use of Videos | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | adidas Uprising - Registration | Isobar India | adidas India Group | Bronze |
| 2 | Breaking the deafening silence – Mirinda Release the pressure | Mindshare India | PepsiCo India Holdings Pvt Ltd | Gold |
| 3 | Clean & Clear Natural Bright gets it right with dynamic messaging | Interactive Avenues | Johnson & Johnson | Bronze |
| C3. Strongest Community Engagement | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Durex Always On | Havas Worldwide | Reckitt Benckiser India | Bronze |
| 2 | RexBot educates India's youth on healthy sex | Interactive Avenues | Reckitt Benckiser India | Silver |
| 3 | ActivKids Immuno Booster - Yes Mom | Msix | Cipla Health Ltd | Silver |
| C4. Most Effective Social Listening | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | U Cypher Naya Sport Naye Superstars | SPARKT | Unisports & Management Pvt Ltd | Bronze |
| 2 | Taj Hotels Palaces Resorts Safaris -Taj.Live: All you have to do is "LISTEN" | Gozoop Online | Tata Group | Silver |
| D. SEARCH & PPC CAMPAIGNS WINNER | ||||
| D1. Best SEO for Website / Universal Search Ranking | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Sharekhan - Local Search | SingleInterface | Sharekhan Ltd | Bronze |
| 2 | Dominating the Top position on Google Search for Myntra via Innovative SEO | INFIDIGIT | Myntra Designs Pvt Ltd | Silver |
| 3 | How Boost used Data and Machine Learning to Identify & target kids online | Mindshare India | GSK Consumer Healthcare India | Silver |
| D3. Best SEM Strategy | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | VIVO Viewtube | WATConsult | VIVO India | Bronze |
| 2 | HIC HIC HURRAH! How Diageo won in search | Mindshare India | Diageo India | Bronze |
| 3 | Godrej Properties: Godrej Late Night Searches | Madison Media | Godrej Properties | Silver |
| 4 | How Johnson and Johnson’s helped new parents find quick solutions for baby care | Interactive Avenues | Johnson & Johnson India | Silver |
| E. SPECIAL AWARDS WINNER | ||||
| E1. Best Integrated Media Campaign - Product/ Services | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | GoAir increased ROI by 8x using Actionable Analytics | Netcore Solutions | Go Airlines (India) Ltd (GoAir) | Bronze |
| 2 | Where are the jobs? | iProspect India | Bloomberg Quint | Silver |
| E2. Best Integrated Media Campaign - Corporate | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Zee TV - Aaj Likhenge Kal | Zee Entertainment Enterprises Ltd | Bronze |
|
| 2 | Microsoft Pledge for Cyber Secure India | Carat Media | Microsoft Corporation (India) Pvt Ltd | Bronze |
| E3. Best Integrated Media Campaign - Social Cause | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Season of Joy Campaign | Webenza India | SPAR Hypermarket | Bronze |
| 2 | REDFM - Mumbai Khadde Mein | Digital Radio Delhi Broadcasting Ltd | Silver |
|
| 3 | Godrej HIT FIK - Excuses don't save life, platelet donation does! | Mindshare India | Godrej Consumer Products Ltd | Gold |
| E4. Best Integrated Media Campaign - Films/ TV Shows / News Shows / Events | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Nicotex - I Can You Can | Msix | Cipla Health Ltd | Bronze |
| 2 | STAR PLUS - TED Talks India Nayi Soch | SPARKT | Star India Pvt Ltd | Silver |
| E5. Most Effective Use of Digital Analytics | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Philips New Range Trimmer Campaign | Carat Media | Philips India Ltd | Bronze |
| 2 | How Boost used Data and Machine Learning to Identify & target kids online | Mindshare India | GSK Consumer Healthcare India | Silver |
| 3 | YousFeed - Personalisation | Adgreetz & Dentsu webchutney | Flipkart | Silver |
| E6. Best Video Advertising – Content | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Nicotex - I Can You Can | Msix | Cipla Health Ltd | Bronze |
| 2 | Castrol Activ Scooter - Girl on a Scooty | Mindshare India | Castrol India Pvt Ltd | Bronze |
| 3 | Girliyapa's Peebuddy | The Viral Fever | First Step Projects | Silver |
| 4 | Kwality Walls Cornetto - Say the Unsaid... | Mindshare India | Hindustan Unilever Ltd | Silver |
| E8. Best Media Campaign – Gender Parity | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Star Plus - Ikyawann - #NotShaadiMaterial | Mindshare India | Star India Pvt Ltd | Bronze |
| 2 | Girliyapa and Whisper’s Sit Improper | The Viral Fever | Procter & Gamble | Silver |
| 3 | #WomenInGreen | White Rivers Media | ALTBalaji | Gold |
| E9. Campaign with the Best ROI | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | How Boost used Data and Machine Learning to Identify & target kids online | Mindshare India | GSK Consumer Healthcare India | Bronze |
| 2 | The Slayer - Innovation propels the business by 7.2X | Logicserve Digital Pvt Ltd | Crompton Greaves Limited | Silver |
| E10. Best Digital Innovation | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Colgate Dental Cream - Colgate Oral Care Month | Redfuse Communications | Colgate Palmolive |
Bronze |
| 2 | Amazon Fire TV Launch | Interactive Avenues | Amazon Seller Services | Silver |
| 3 | National Geographic - Earth Live | Isobar India | NGC Network (India) Pvt Ltd | Silver |
| E11. Most Effective Use of AI for a Campaign and Business Optimisation | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | How Boost used Data and Machine Learning to Identify & target kids online | Mindshare India | GSK Consumer Healthcare India | Bronze |
| 2 | YousFeed - Personalisation | Adgreetz & Dentsu webchutney | Flipkart | Bronze |
| 3 | How Johnson and Johnson’s helped new parents find quick solutions for baby care | Interactive Avenues | Johnson & Johnson India | Silver |
| E12. Best use of AR or VR | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Mera Joota Hai Japani - India's First virtual reality video with spatial sound. | Qyuki | Flipkart | Bronze |
| 2 | Entertainment Wish Karo, DishTV Karo | Affle In Association With DishTV | Zee Entertainment Enterprises Ltd | Bronze |
| 3 | #StreetArt for the #ArtOfStreet | Grapes Digital | Maruti Suzuki | Silver |
| E13. Best Use of Experiential Tech for Digital & Physical Experiences | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | National Geographic - Earth Live | Isobar India | NGC Network (India) Pvt Ltd | Silver |
| 2 | Kaun Banega Crorepati JIO Play Along | Sony Pictures Networks India Pvt Ltd | Gold |
|
| E14. Breakthrough Technology as Part of a Campaign | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Godrej HIT | InteractionOne Solutions | Godrej Consumer Products Ltd | Bronze |
| 2 | CEAT Tyres creates a First Time Ingame Innovation to drive Road Safety message | Isobar India | RPG Group | Bronze |
| 3 | Rakhi with Fabelle | Madison Media | ITC Ltd | Silver |
| E15. Location-based or Proximity Marketing Campaign of the Year | ||||
| S.no | Campaign | Agency | Company | Metal |
| 1 | Castrol CRB Mini Truck ka Shiksha Kendra | Mindshare India | Castrol India Pvt Ltd | Bronze |
| 2 | Harpic - Banega Swachh India | Affle In Association with Interactive Avenues | Reckitt Benckiser India | Silver |
| 3 | India's First AI based SMS, S-Cross | Grapes Digital | Maruti Suzuki | Silver |
| IDMA Person of the Year 2018 | ||||
| Ashish Hemrajani from BookMyShow | ||||
| Best Digital and Social Media Advertiser of the Year | ||||
| Aditya Birla Group | ||||
| Zee Entertainment Enterprises Ltd | ||||
| Best Digital and Social Media Agency of the Year | ||||
| Mindshare India |


FOI release
Freedom of information request and disclosure on the BSF programme's cancellation.
Can the Department provide information relating to the incorrect release of schools affected by cancellation of the BSF programme between 5 July and 16 July 2010?
This should include correspondence - letters and emails - between the Secretary of State for Education, his private office and Department officials.
The Department holds information within scope of the request. However, it has considered that the exemption at section 35(1)(a) of the Act which allows for the withholding of information if it relates to the formulation or development of Government policy to be engaged in this case.
Under section 35, the Department is required to balance the public interest in withholding the information against the public interest in disclosing it. Having done so, the Department has concluded that the public interest in maintaining the exemption and not disclosing the information outweighs the public interest in disclosure in this instance.
The particular factors which the Department considered when deciding where the public interest lay are set out below.
There is a general public interest in disclosure. Knowledge of the way Government works increases if the information on which decisions have been made is available.
This can lead to public contribution to the policy making process becoming more effective. There is a general public interest in being able to see if ministers are being briefed effectively on the key areas of policy the Department is taking forward.
Conversely, it is in the public interest that the formulation of Government policy and Government decision-making can proceed in the self-contained space needed to ensure that it is done well. Good government depends on good decision-making and these needs to be based on the best advice available and a full consideration of the options.
Without protecting the ability for ministers and senior officials to receive free and frank advice, there is likely to be a corrosive effect on the conduct of good government, with a risk that decision-making will become less fully-informed and will be recorded inadequately.
It is therefore the Department’s view that the public interest in non-disclosure outweighs the public interest in disclosure in this case.
However, it may be useful to read the transcripts of the select committee sessions on 28 and 30 July 2010, where Tim Byles of Partnership for Schools and the Secretary of State explain the BSF process, including the incorrect list of affected schools on 5 July.


Topicstarter
Right now if you look at the weapon stats page you can filter for the 4 kits. Which is like sorting it for assault rifle/carbine/lmgs/snipers
I would like to see shotguns, PDW and pistol filters added.
BrainFooLong
Administrator
Good idea. When you can make a list for me of all weapons for this 3 new groups, i can make filters for them.
Topicstarter
Pistols:
M9 / M9 TACT / M9 SUPP
MP443 / MP443 TACT / MP443 SUPP
MP412 REX
93R
G17C / G17C SUPP
G18 / G18 SUPP
.44 MAGNUM / .44 SCOPED
M1911 / M1911 TACT / M1911 SUPP
Shotguns:
870MCS
M1014
SAIGA 12K
USAS-12
MK3A1
DAO-12
PDW:
MP7
PP-2000
UMP-45
PDW-R
P90
AS VAL
PP-19
BrainFooLong
Administrator
Thank you, maybe i can integrate this already in the next version.
Otherwise it comes in overnext version.


{% extends 'Ecommerce/basic.html' %} {% load static %} {% block head %} {% endblock %} {% block body %} {% load static %}
{{ pro.price }}
No reviews about this product yet
{% else %}--- Showing {{review|length}} reviews
{% for rev in review %}{{rev.Review}}
You must be logged in to write a review
and add this item to cart


Topgallant driver grog mutiny six pounders. Coxswain case shot square-rigged carouser Privateer. Jury mast weigh anchor mizzenmast strike colors draught. Boatswain wherry hulk rum poop deck. Sloop sheet gangway bucko yawl. Nelsons folly hail-shot coxswain line parrel.
Ye yardarm yo-ho-ho gangplank wherry scurvy interloper careen furl stern. American Main transom Letter of Marque bilged on her anchor to go on account splice the main brace chantey shrouds jack topgallant. Lass clipper mizzen Arr piracy nipper crack Jennys tea cup bounty chase Plate Fleet.
Coffer yo-ho-ho topsail gangplank Sea Legs me brigantine haul wind crack Jennys tea cup Nelsons folly.
Piracy Brethren of the Coast fore quarterdeck Jack Tar bring a spring upon her cable pinnace crow's nest me cackle fruit. Long boat barkadeer scurvy fathom chandler rigging brig chase guns cutlass jury mast. Loot furl scurvy Plate Fleet broadside weigh anchor Pieces of Eight Letter of Marque pink Barbary Coast.


--- layout: post title: Covers and postcards date: 2008-05-28 18:18:21.000000000 -07:00 categories: - book news tags: [] status: publish type: post published: true meta: _edit_last: '1' author: login: ckelty email<EMAIL_ADDRESS>display_name: ckelty first_name: Christopher last_name: Kelty excerpt: !ruby/object:Hpricot::Doc options: {} ---
Books are on their way...
I have covers, and postcards (Front and Back) and flyers....


ABOUT ME
Hi, my name is Raden and I am a Product Designer based in Barcelona. I enjoy solving complex problems that I find meaningful. I am a design thinker with a technical background and a passion for making a positive impact on people through my work.
Raised in a family of artists, I quickly developed a great appreciation for art and aesthetics. My desire to solve problems and impact people’s lives, however, led me in the direction of becoming a software engineer. Nevertheless, during my five years of work, I was unfulfilled and wanted to re-engage my creative side. I decided to pursue a path in UX design, where I am now combining my coding and artistic talents, working relentlessly to solve problems and enhance experiences.


An interconnected world requires a new breed of solutions.
Solutions that are creative and quantitative, built on statistics, analytics, and visualization.
We deliver strategic insights to nonprofits and startups to optimize business, discover solutions, and understand data.
UCLA students founded Bruinmetrics to answer the needs of the university community and professional services industry. With our collaborative approach, Bruinmetrics provides valuable insights for clients and unique work for students .
Data-First.
With a distinct specialization in data, our insights are always supported by quantitative methods. Our business decisions minimize bias and maximize results, supported by healthy skepticism and visual storytelling.
Creative.
Our consultants hail from a wide variety of backgrounds, and these unique perspectives make it possible to creatively apply scientific and design principles to drive results.
Motivated.
We are passionate about learning more and iterating faster. With a shared love for data science, we consult because it’s fun, collaborative, memorable, and valuable.
Experience.
We’ll give you the tools, team, and support to learn by doing.
Mentorship.
New to data? Our team structure ensures collaboration and guidance.
Data veteran? Gain valuable leadership and project management experience.
Friendship.
A community of best-of-class bruins.


Installation¶
Link your own Python Distribution to MSC.Marc Mentat® (Windows)¶
In order to use your own Python Distribution for MSC.Marc Mentat®, make sure to download exactly the same version of Python as the one which comes bundled with MSC.Marc Mentat®. The Python version is denoted in the Marc and Mentat Release Guide. The easiest way on Windows is to use WinPython, as it installs the whole Python distribution in a single folder without any modifications to the system. In Spyder, add the path to the modules py_mentat and py_post. Scripts started inside Spyder (shortcut F5) are now able to establish a connection to MSC.Marc Mentat®.
- Download WinPython, unzip and install to C:\WinPython-64bit-3.x.x.x
- open Spyder
- Tools - PYTHONPATH manager - add path C:\MSC.Software\Marc\20xx.x.x\mentat20xx\shlib\win64
- Synchronize… - No - close
- restart Spyder
Download PrePostPy¶
- Download this repo as ZIP-file, unzip it and add the unzipped location to your PYTHONPATH in Spyder (same procedure as above).
- open Spyder
- Tools - PYTHONPATH manager - add path C:\Path\to\prepostpy_package
- Synchronize… - No - close
- restart Spyder
Import PrePostPy¶
Create a new script in Spyder and run the following script to verify if everything is set up correctly. On the first run the connection has to be allowed in the firewall.
import prepostpy as pp
F = pp.File('temp.mud')
F.item.N1 = pp.Node([0,0,-0.01])
MConn = pp.MentatConnection(version='latest')
with MConn:
F.tomentat()


| Package | Description |
|---|---|
| org.apache.fop.afp.goca |
Contains a collection of AFP font related classes.
|
| org.apache.fop.afp.modca |
Contains a collection of AFP Mixed Object Document Content Architecture (MO:DCA) structured objects.
|
| org.apache.fop.afp.modca.triplets |
Contains a collection of AFP Mixed Object Document Content Architecture (MO:DCA) triplet classes.
|
| Modifier and Type | Class and Description |
|---|---|
class |
AbstractGraphicsCoord
A base class encapsulating the structure of coordinate based GOCA objects
|
class |
AbstractGraphicsDrawingOrder
A base GOCA drawing order
|
class |
AbstractGraphicsDrawingOrderContainer
A base container of prepared structured AFP objects
|
class |
GraphicsAreaBegin
The beginning of a filled region (graphics area).
|
class |
GraphicsAreaEnd
The end of a filled region (graphics area).
|
class |
GraphicsBox
A GOCA graphics rectangular box
|
class |
GraphicsChainedSegment
A GOCA graphics segment
|
class |
GraphicsCharacterString
A GOCA graphics string
|
class |
GraphicsData
A GOCA graphics data
|
class |
GraphicsEndProlog
The end of a prolog.
|
class |
GraphicsFillet
A GOCA graphics curved tangential line to a specified set of
straight lines drawn from the given position or current position
|
class |
GraphicsFullArc
A GOCA graphics arc (circle/ellipse)
|
class |
GraphicsImage
A GOCA Image
|
class |
GraphicsLine
A GOCA graphics straight line drawn from the
given absolute position
|
class |
GraphicsSetArcParameters
Sets the arc parameters for a GOCA graphics arc (circle/ellipse)
|
class |
GraphicsSetCharacterSet
Sets the current character set (font) to be used for following graphics strings
|
class |
GraphicsSetCurrentPosition
Sets the current painting position of the graphics object
|
class |
GraphicsSetFractionalLineWidth
Sets the line width to use when stroking GOCA shapes (structured fields)
|
class |
GraphicsSetLineType
Sets the value of the current line type attribute when stroking GOCA shapes (structured fields)
|
class |
GraphicsSetLineWidth
Sets the line width to use when stroking GOCA shapes (structured fields)
|
class |
GraphicsSetMix
Sets the foreground mix mode.
|
class |
GraphicsSetPatternSymbol
Sets the pattern symbol to use when filling following GOCA structured fields
|
class |
GraphicsSetProcessColor
Sets the current processing color for the following GOCA structured fields
|
| Modifier and Type | Method and Description |
|---|---|
StructuredData |
GraphicsData.removeCurrentSegment()
Removes the current segment from this graphics data
|
StructuredData |
AbstractGraphicsDrawingOrderContainer.removeLast()
Removes the last drawing order from this container and returns it
|
| Modifier and Type | Method and Description |
|---|---|
void |
GraphicsData.addObject(StructuredData object)
Adds a given graphics object to this container
|
void |
AbstractGraphicsDrawingOrderContainer.addObject(StructuredData object)
Adds a given graphics object to this container
|
| Modifier and Type | Class and Description |
|---|---|
static class |
ActiveEnvironmentGroup.FontFullyQualifiedNameTriplet |
| Modifier and Type | Method and Description |
|---|---|
void |
GraphicsObject.addObject(StructuredData object) |
| Modifier and Type | Interface and Description |
|---|---|
interface |
Triplet
Triplet interface.
|
| Modifier and Type | Class and Description |
|---|---|
class |
AbstractTriplet
A simple implementation of a MOD:CA triplet
|
class |
AttributeQualifierTriplet
The attribute qualifier triplet is used to specify a qualifier for a document
attribute.
|
class |
AttributeValueTriplet
The attribute value triplet is used to specify a value for a document
attribute.
|
class |
CommentTriplet
An inline comment triplet.
|
class |
DescriptorPositionTriplet
Associates an ObjectAreaPosition with and ObjectAreaDescriptor structured field
|
class |
EncodingTriplet
Represents a CCSID encoding triplet.
|
class |
ExtendedResourceLocalIdentifierTriplet
The Extended Resource Local Identifier triplet specifies a resource type and a
four byte local identifier or LID.
|
class |
FullyQualifiedNameTriplet
A Fully Qualified Name triplet enable the identification and referencing of
objects using Gloabl Identifiers (GIDs).
|
class |
MappingOptionTriplet
Specifies the mapping of data object presentation space to object area
|
class |
MeasurementUnitsTriplet
The Measurement Units triplet is used to specify the units of measure
for a presentation space
|
class |
ObjectAreaSizeTriplet
The Object Area Size triplet is used to specify the extent of an object area
in the X and Y directions
|
class |
ObjectByteExtentTriplet
The Object Byte Extent triplet is used to specify the number of bytes contained in an object
|
class |
ObjectClassificationTriplet
The Object Classification is used to classify and identify object data.
|
class |
PresentationSpaceMixingRulesTriplet
This triplet is used to specify the resulting appearance when data in a new
presentation space is merged with data in an existing presentation space.
|
class |
PresentationSpaceResetMixingTriplet
This triplet is used to specify the resulting appearance when data in a new
presentation space is merged with data in an existing presentation space.
|
class |
ResourceObjectTypeTriplet
A Resource Object Type Triplet
|
Copyright 1999-2020 The Apache Software Foundation. All Rights Reserved.


Used throughout the Pattern stack, Minimal is a simple Java API that exposes minimalist interfaces for common functions including identity generation, JSON parsing and reflection.
Minimal is a simple Java API that exposes minimalist interfaces for common functions including identity generation, JSON parsing and reflection.
To get started, add the following dependency to your depedency list:
<dependency>
<groupId>fm.pattern</groupId>
<artifactId>minimal</artifactId>
<version>1.0.0</version>
</dependency>
The id generator uses a cryptographically strong random number generator to produce sequences of alphanumeric strings that can be used as unique identifiers.
By default, the id generator will produce a 25 character length alphanumeric string, with a mix of uppercase and lowercase characters:
IdGenerator.generateId() => "jDWatQsPtRNOMhYAnVWUDF3LE"
You can specify the length of the id to generate by providing a length argument:
IdGenerator.generateId(5) => "pciIi"
IdGenerator.generateId(50) => "Sf3hcRp8yIveqZbkx3AMTpomZzbDVHfxyOIyGzjZCaPaGdc0NC"
You can add a prefix to generated ids. The id generator will add an underscore between the specified prefix and the (default 25 character length) alphanumeric sequence.
IdGenerator.generateId("txn") => "txn_Lh2LRvtK4euznW686ScmNNkw4"
You can specify a prefix and the length of the id to generate:
IdGenerator.generateId("txn", 10) => "txn_qGoxTSqc30"
IdGenerator.generateId("txn", 30) => "txn_6CKbkcPQgk8OCONGu82Tv2rv664P2H"
The JSON API exposes a JavaScript-inspired interface on top of the excellent Jackson library for JSON parsing.
Person person = new Person("John", "Smith");
JSON.stringify(person) => {"firstName":"John","lastName":"Smith"}
This method will throw a JsonParsingException at runtime if the Java value cannot be serialized.
Tip: If you override the toString() implementation to generate JSON it becomes simple to produce well formatted JSON logs, and really useful when debugging and troubleshooting.
public class Account {
@Override
public String toString() {
return JSON.stringify(this);
}
}
Account account = new Account();
// Logs a well formatted JSON string with the account's current state.
logger.info(account);
// Prints a well formatted JSON string with the account's current state instead of it's hash code.
System.out.pritnln(account);
Person person = JSON.parse("{\"firstName\":\"John\",\"lastName\":\"Smith\"}", Person.class);
System.out.pritnln(person.getFirstName()); => "John"
System.out.pritnln(person.getLastName()); => "Smith"
This method will throw a JsonParsingException at runtime if the JSON string cannot be deserialized.
The Reflection API provides a map-like interface on top of the Java Reflection API for getting and setting property values on Java objects. We’ll run through a number of examples using the following object model:
public class Entity {
private String id;
...
}
public class Address extends Entity {
private String suburb;
...
}
public class Person extends Entity {
private String name;
private Address address;
...
}
Address address = new Address();
address.setId("1234abcd");
address.setSuburb("Bondi");
Person person = new Person();
person.setId("abcd12345");
person.setName("Sally");
person.setAddress(address);
The get API returns a property value for a given property name. If no such property value exists, a null value is returned. Property values returned from the get API will be of type Object by default, but you can specify the return type explicitly to override the default behaviour.
// Retrieves the 'name' property from the Person object.
Reflection.get(person, "name"); => "Sally"
// Retrieves the 'id' property from the Person object superclass.
Reflection.get(person, "id"); => "abcd12345"
// Retrieves the 'suburb' property from the composed Address object.
Reflection.get(person, "address.suburb"); => "Bondi"
// Retrieves the 'id' property from the composed Address object superclass.
Reflection.get(person, "address.id"); => "1234abcd"
// Retrieves the 'address' property from the Person object, returned as an Address through an explicit cast.
Address address = (Address) Reflection.get(person, "address");
// Retrieves the 'address' property from the Person object, returned as an Address by specifying a return type.
Address address = Reflection.get(person, "address", Address.class);
The set API sets a property value for a given property name. An updated object instance is returned when a property value is set successfully, and null otherwise.
// Sets the 'name' property on the Person object.
Reflection.set(person, "name", "Suzan");
// Sets the 'id' property on the Person object superclass.
Reflection.set(person, "id", "11111");
// Sets the 'suburb' property on the composed Address object.
Reflection.set(person, "address.suburb", "St. Kilda");
// Sets the 'id' property on the composed Address object superclass.
Reflection.set(person, "address.id", "22222");
// Setting an invalid property value will return a null instance.
Person updated = Reflection.set(person, "invalid_property", "12345");
System.out.println(updated) => null
// Setting a valid property value will return the updated instance.
Person updated = Reflection.set(person, "name", "Katherine");
System.out.println(updated) => {"id":"11111", "name":"Katherine", ...}


--- layout: page title: STAT 445/645 — Fall 2020 ---
Three dimensional bell surface of a multivariate Gaussian distribution. Courtesy of Wikimedia Commons (CC 3.0)
This is the course archive page for Introduction to Statistical Computing, STAT 445/645 FALL 2020 – Section 1001. Please see the menus below for class resources, handouts, lectures and activities archived from the class.
The archive of lectures, handouts and activities is below according to the semester schedule.
| Week | Lecture slides | Activities | Homework, quizzes and exams |
|---|---|---|---|
| 08/24 - 08/28 | R for Reproducible Scientific Analysis, sections 1 & 3 - 5. | Activity sheets: Supplementary Materials: |
Homework 1:
|
| 08/31 - 09/04 | R for Reproducible Scientific Analysis, sections 6, 7 & 9. | Activity sheets: Supplementary Materials: |
Homework 2:
|
| 09/07 - 09/11 |
R for Reproducible Scientific Analysis, sections 8 & 11.
|
Activity sheets: Supplementary Materials: |
Homework 3:
|
| 09/14 - 09/18 | R for Reproducible Scientific Analysis, sections 10 & 15. | Supplementary Materials: |
Midterm 1: Exploratory Data Analysis Project
|
| 09/21 - 09/25 | Probability and discrete distributions | Work on Miderm 1 Project | |
| 09/28 - 10/02 | Continuous univariate distibutions | Supplementary Materials: |
Quiz 1:
|
| 10/05 - 10/09 | Univariate statistical analysis | Supplementary Materials: |
Quiz 2:
|
| 10/12 - 10/16 | Review day and Midterm 2
|
Supplementary materials |
Midterm 2:
|
| 10/19 - 10/23 | Matrix algebra and numerical integration | Supplementary Materials: |
Quiz 3:
|
| 10/26 - 10/30 | Numerical differentiation and unconstrained optimization |
Homework 4:
|
|
| 11/02 - 11/06 | Multivariate distributions |
Midterm 3:
|
|
| 11/09 - 11/13 | Midterm 3 - take home
|
Midterm 3 Due Friday at 11:59 PM in Canvas | |
| 11/16 - 11/20 | Multivariate distributions part 2 and regression part 1 | ||
| 11/23 - 11/25 | Regression part 2 and Thanksgiving break | ||
| 11/30 - 12/04 | Maximum likelihood estimation | ||
| 12/07 - 12/09 | Final project prep
| Final project:
|


[gecode-users] Problem extensional between BoolVars and IntVar
Christian Schulte
cschulte at kth.se
Wed Oct 9 11:00:11 CEST 2013
Dear Mohamed,
I only have an inefficient solution here: you can introduce IntVars y1 and
y2 and use the channel constraint:
channel(home, x1, y1); channel(home, x2, y2);
and then you can use y1 and y2 together with x3 and x4 and the extensional
constraint.
Best
Christian
--
Christian Schulte, Professor of Computer Science, KTH,
www.ict.kth.se/~cschulte/
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Mohamed Rezgui
Sent: Wednesday, October 09, 2013 10:53 AM
To: users at gecode.org
Subject: [gecode-users] Problem extensional between BoolVars and IntVar
Dear Sir,
I would like to know how can I use Gecode with extensional between BoolVar
and IntVar
I show you my problem :
I have boolvars : x1 x2
and intvars x3 x4
I have some valid tuples :
0 1 3 4
0 0 6 6
1 1 7 3
How can I use constraint Gecode::extensional to use BoolVar and IntVar
together ?
This is not the case with Gecode 4.2.0
Maybe do I use a clause constraint to express the constraint extensional for
BooVar and the constraint extensional for IntVar ?
--
Best Regards,
Mohamed REZGUI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gecode.org/pipermail/users/attachments/20131009/4b699dd7/attachment.html>
More information about the users
mailing list


Forecast for tomorrow:
High: 50 degrees Low: 25 degrees Mostly Cloudy
Sub-Heading
Click logo above to return to main page.


We are here to pamper your Tarantula. Walks, training, babysitting, and more for your cool fuzzy pet!
We won the prestigious award, Best Care by The Tarantula Times. We were in the 2016 Fall issue!
The team is all made up of people who are Tarantula enthusiasts. Our names are Max, Billy, Stacy, & Johnny.


all books
GET /api/v1/books
Request
Headers
Route
GET /api/v1/books
Response
Headers
Status
200 OK
Body
[
{
"id": 1,
"title": "To Sail Beyond the Sunset",
"description": "No statement can catch the ChuckNorrisException.",
"authors": [
]
},
{
"id": 2,
"title": "Beneath the Bleeding",
"description": "Chuck Norris doesn't believe in floating point numbers because they can't be typed on his binary keyboard.",
"authors": [
]
},
{
"id": 3,
"title": "A Catskill Eagle",
"description": "Chuck Norris is immutable. If something's going to change, it's going to have to be the rest of the universe.",
"authors": [
]
},
{
"id": 4,
"title": "The Cricket on the Hearth",
"description": "Chuck Norris doesn't need an OS.",
"authors": [
]
},
{
"id": 5,
"title": "The Wind's Twelve Quarters",
"description": "Chuck Norris doesn't need the cloud to scale his applications, he uses his laptop.",
"authors": [
]
},
{
"id": 6,
"title": "I Know Why the Caged Bird Sings",
"description": "There is no need to try catching Chuck Norris' exceptions for recovery; every single throw he does is fatal.",
"authors": [
]
},
{
"id": 7,
"title": "Brandy of the Damned",
"description": "You don't disable the Chuck Norris plug-in, it disables you.",
"authors": [
]
},
{
"id": 8,
"title": "The Other Side of Silence",
"description": "When Chuck Norris gives a method an argument, the method loses.",
"authors": [
]
},
{
"id": 9,
"title": "The Widening Gyre",
"description": "Chuck Norris can recite π. Backwards.",
"authors": [
]
},
{
"id": 10,
"title": "Eyeless in Gaza",
"description": "Chuck Norris is immutable. If something's going to change, it's going to have to be the rest of the universe.",
"authors": [
]
}
]


Test coverage user interface for C and C++
| Operating System | Platform | Compiler Version | ggcov Version | Notes |
| Ubuntu,Debian | i386,x86_64 | 4.6, 4.7, 4.8, 4.9, 5.0, 5.1, 5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.4, 6.5, 7.0, 7.1, 7.2, 7.3, 7.4, 8.1, 8.2, 8.3, 9.0, 9.1, 9.2, 9.3, 10.0 | 0.10 | Works. |
| Ubuntu Maverick | i386,x86_64 | 4.5.2 | 0.8.3 | Works. |
| Ubuntu Karmic | i386,x86_64 | 4.4.1 | 0.8.2 | Works. |
| Ubuntu Jaunty | i386 | 4.3 | 0.8.1 | Works. |
| Ubuntu Dapper | i386 | 4.1 | 0.8 | Works. |
| Ubuntu Dapper | i386 | 4.0.3 | 0.8 | Works. |
| Ubuntu Dapper | i386 | 3.4 | 0.8 | Works. |
| Mandrake 10.2 | i386 | vendor | 0.8 | Works. |
| Fedora Core 4 | i386 | vendor | 0.7 | Works. |
| Fedora Core 3 | i386 | stock 4.1.1 | 0.8 | Works. |
| Fedora Core 3 | i386 | stock 4.0.0 | 0.8 | Works. |
| Fedora Core 3 | i386 | vendor | 0.4 | Works. |
| SLES 9 | ia64 | vendor | 0.4 | Works, with the exception of call graph data. |
| Mandrake 10.0 | i386 | vendor | 0.4 | Mostly works. Some call coverage data appears to be wrong |
| Red Hat Linux 7.3 (Valhalla) | i386 | 2.96 | 0.2 | Mostly works, but call coverage data is wrong due to broken data files written by gcc 2.96 (gcov also misreports calls). |
| Red Hat Linux 9 (Shrike) | i386 | 3.2.2 | 0.2 | Works. |
| SuSE Linux 8.2 | i386 | 3.2 | 0.1.6 | SuSE provide a gcc which claims to be version 3.2 but contains early 3.3 features, in particular it writes completely different new .bbg and .da file formats. DO NOT USE version 0.1.5 on SuSE 8.2, the new file format causes it to eat all your RAM and crash on startup. Try version 0.1.6. |
| SGI Irix 6.5.20 | MIPS | fw | 0.1.3 | Compiles and runs. Only tested in n32 ABI. Code to read call graph data from MIPS object files has not been written, and wont be because the bfd library is missing from the Irix freeware gcc package. |