dataesr/scientific-paragraphs-categorization huggingface dataset:
The diffusion NMR data was also used to quantify choline compounds (3. 3-3. 18 ppm) and glycoproteins (2. 15-1. 9 ppm), based on peak deconvolutions. In this study, lipoprotein profiles showed significantly lower plasma concentrations of cholesterol-IDL, triacylglycerides-IDL and HDL in mothers of growth-restricted fetuses compared to controls. 1 H NMR-based lipidomic analysis of HDL lipoprotein of plasma samples, isolated from non-HDL lipoproteins by precipitation, helps in the characterization of the atheroprotective function of HDL and the identification of novel biomarkers of cardiovascular risk  [18]. Jimenez et al. reported an extensive NMR trial of quantitative lipoprotein in human blood serum and plasma. They quantified 105 lipoprotein subclasses without physical separation, using an algorithm based on the deconvolution of the lipid signals combined with multivariate statistical model building  [19].
High resolution MS can provide users with unrivaled resolution and the critical advantage of accurately defining the exact elemental composition of individual ion peaks over MS with unit resolution. These technologies had a lower linear range compared to QqQ, but this point is greatly improved with the new generation of these instruments. With MS detection, the calculation of individual lipid concentration from lipidomic datasets comprises different steps and requires specific assumptions that affect the estimation. These steps include (i) normalization with the corresponding ISTD; (ii) correction for isotopic overlap and isotope distribution effects; (iii) normalization for the starting sample amount; (iv) calculation of absolute concentrations, based on spiked ISTD, calibration curves and response/correction factors; and (v) drift/batch corrections  [61].
g. , amino acids, vitamins, carotenoids, etc. ), fatty acids, and total cholesterol. The comparison to this reference material can be easily obtained with LipidQC software  [68]. This is a good option even if its stability is not guaranteed. In any case, the easiest way to have a quality control is to use a pool of all the samples to be analyzed, or if it is not convenient (e. g. for cell or tissues) a pool of the extract ready to analyzed, which can be regularly used during the experiment.
Acknowledgments: This work was supported by the  French National Infrastructure MetaboHUB   ANR-11-INBS-010 , by the  Région Occitanie , the  Centre National de la Recherche Scientifique (CNRS) , the  Institut National de la Recherche Agronomique (INRA)  and the  Institut National de la Santé et de la Recherche Medicale (Inserm).
The Message Authenticator Algorithm (MAA) is one of the first cryptographic functions for computing a Message Authentication Code. Between 1987 and 2001, the MAA was adopted in international standards (ISO 8730 and ISO 8731-2) to ensure the authenticity and integrity of banking transactions. In 1990 and 1991, three formal, yet non-executable, specifications of the MAA (in VDM, Z, and LOTOS) were developed at NPL. Since then, five formal executable specifications of the MAA (in LOTOS, LNT, and term rewrite systems) have been designed at INRIA Grenoble. This article provides an overview of the MAA and compares its formal specifications with respect to common-sense criteria, such as conciseness, readability, and efficiency of code generation.
The Message Authenticator Algorithm (MAA) In data security, a Message Authentication Code (MAC) is a short sequence of bits that is computed from a given message; the MAC ensures both the authenticity and integrity of the message, i. e. , that the message sender is the stated one and that the message contents have not been altered. A MAC is more than a mere checksum, as it must be secure enough to defeat attacks; its design usually involves cryptographic keys shared between the message sender and receiver. One of the first MAC algorithms to gain widespread acceptance was the MAA, which we now present in more detail.
Informal Specifications of the MAA We consider the 1988 NPL technical report  [4]  to be the reference document for the MAA definition in natural language. Indeed, this technical report is freely available from the NPL library or can be downloaded from the web, whereas the (withdrawn) ISO standards 8730 and 8731-2 need to be purchased. The algorithm described in  [4]  is identical to the MAA definition given in ISO 8731-2. Moreover,  [4]  provides the source code of two different implementations of the MAA, in BASIC (227 lines 3  ) and C (182 lines 4  ). None of these implementations supports the aforementioned "mode of operation"; we therefore added 31 lines of C code implementing this missing functionality. Although the C code was written in 1987 for the Turbo C and Zorland compilers, it still compiles and executes properly today after a few simple corrections, provided that long integers are set to 32 bits 5.
4 gives results for a 588-block message. In both series of test vectors, we found mistakes, which we document and for which we give corrections in Annexes A and B of the present article. 3 Formal Specifications of the MAA As far as we know, not less than eight formal specifications have been produced for the MAA. We present each of them in turn, drawing a clear distinction between non-executable and executable speci-fications. To unambiguously designate these specifications, we adopt the following naming convention: LANG-XX refers to the formal specification written in language LANG during year XX.
Non-Executable Formal Specifications For cryptographic protocols, an informal specification is often not precise enough, and the MAA makes no exception. For instance, G. I. Parkin and G. O'Neill devoted four pages in  [25, Sect. 3]  and  [26, Sect. 3]  to discuss all possible interpretations of the MAA definition in natural language. The need for unambiguous specifications was certainly felt by stakeholders, as three formal specifications of the MAA were developed at NPL in the early 90s, as part of a comparative study in which common examples were modelled using various formal methods. All these specifications were non-executable, in the sense that MAA implementations had to be developed manually and could not be automatically derived from the formal specifications -at least, using the software tools available at that time.
Based upon Knuth's "literate programming" approach, this work resulted in a 57-page technical report  [20] , in which formal fragments (totalling 608 lines of Z code) are inserted in the natural-language description of the MAA. This formal specification was designed to be as abstract as possible, not to constrain implementations unduly, and it was lightly verified using a type-checking tool. • LOTOS-91 : In 1991, Harold B. Munster produced another formal specification of the MAA in LOTOS presented in a 94-page technical report  [24]   6. This specification (16 pages, 438 lines) uses only the data part of LOTOS (namely, abstract data types inspired from the ACT ONE language  [7] [22] ), importing the predefined LOTOS libraries for octets, strings, natural numbers in unary, binary, and decimal notation; the behavioural part of LOTOS, which serves to describe concurrent processes, is not used at all.
Executable Formal Specifications As a continuation of the work undertaken at NPL, five formal specifications of the MAA have been developed at INRIA Grenoble. These specifications are executable, in the sense that all expressions that contain neither free variables nor infinite recursion can be given to some interpretation engine and evaluated to produce relevant results. But executable also means that these specifications can be compiled automatically (e. g. , using the translators of the CADP toolbox  [10] ) into some executable program that will be run to generate the expected results. Let us review these five specifications: • LOTOS-92 : In 1992, Hubert Garavel and Philippe Turlier, taking LOTOS-91 as a starting point, gradually transformed it to obtain an executable specification from which the CAESAR.
ADT compiler  [8] [13]  could generate C code automatically. Their goal was to remain as close as possible to the original LOTOS specification of Harold B. Munster, so as to demonstrate that limited changes were sufficient to turn a non-executable LOTOS specification into an executable one. The aforementioned causes of non-executability in LOTOS-91 were addressed by fulfilling the additional semantic constraints set on LOTOS by the CAESAR. ADT compiler to make sure that LOTOS specifications are executable: -The algebraic equations, which are not oriented in standard LOTOS, were turned into term rewrite rules, which are oriented from left to right and, thus, more amenable to efficient translation. -A distinction was made between constructor and non-constructor operations, and the discipline of "free" constructors required by CAESAR.
ADT  [8]  was enforced: namely, each rule defining a non-constructor f must have the form either " f (p 1 ,. , p n ) → e" or "c 1 ,. , c m ⇒ f (p 1 ,. , p n ) → e", where each p i is a term containing only constructors and free variables, and where c 1 ,. , c m , and e are terms whose variables must be also present in some p i. -To avoid issues with the unary notation of natural numbers, the Nat sort was implemented manually as a C type (32-bit unsigned integer). Similarly, a few operations on sort Nat (integer constants, addition, multiplication, etc. ) were also implemented by manually written C functions -the ability to import externally defined C types and functions, and to combine them with automatically generated C code being a distinctive feature of the CAESAR. ADT compiler. Additionally, all occurrences of the sort BitString used for the binary notation of natural numbers, octets, and blocks were eliminated from the MAA specification.
This resulted in a 641-line LOTOS specification, together with two C files (63 lines in total) implementing the LOTOS sorts and operations defined externally. The CAESAR. ADT compiler translated this LOTOS specification into C code that, combined with a small handwritten main program (161 lines of C code), could compute the MAC value corresponding to a message and a key. • LNT-16 : In February 2016, Wendelin Serwe manually translated LOTOS-92 into LNT  [1] , which is the most recent specification language supported by the CADP toolbox and the state-ofthe-art replacement for LOTOS  [11]. This translation was done in a systematic way, the goal being to emphasize common structure and similarities between the LOTOS and LNT specifications. The resulting 543-line LNT specification thus has the style of algebraic specifications and functional programs, relying massively on pattern matching and recursive functions.
g. , MUL1, MUL2, MUL2A, Prelude, Coda, MAC, etc. ) have been simplified by taking advantage of the imperative style LNT, i. e. , mutable variables and assignments; many auxiliary functions have been gathered and replaced by a few larger functions (e. g. , PreludeJ, PreludeK, PreludeHJ, and PreludeHK) also written in the imperative style. These changes resulted in a 268-line LNT specification with a 136-line companion C file, which have nearly the same size as LOTOS-17 , although the LNT version is more readable and closer to the original MAA specification  [4] , also expressed in the imperative style. Taken alone, the LNT code has approximately the same size as VDM-90 , the non-executable specification that was included as a formal annex in the MAA standard  [17]. As for REC-17 , the LNT specification was then enriched with a collection of "assert" statements implementing: (i) the test vectors listed in Tables  1 to 6  of [17, Annex A] and  [4] ; (ii) the test vectors of  [16, Annex E.
In such languages where functions return only a single result, there are two different options for describing functions with multiple results such as Prelude. The first option is return a unique result of some compound type (record, tuple, array, etc. ). For instance, both VDM-90 and Z-91 describe Prelude as a function taking a pair of blocks and returning a result of a new type (called Key-Constant  [25, Sections 2. 2. 2 and 2. 2. 7]  or DerivedSpace  [20, pages 45-46] ) defined as a sextuple of blocks. LOTOS-91 and LOTOS-17 adopt a similar approach by defining Prelude to return a result of a new sort ThreePairs, which is a triple of Pair values, where sort Pair is itself defined as a pair of blocks. Other examples can be found in the binary adders and multipliers of REC-17 ; for instance, the 8-bit adder returns a result of sort OctetSum that is a pair gathering a sum (of sort Octet) and a carry (of sort Sum).
Validation of MAA Specifications The two most recent specifications of the MAA have been validated as follows: • LOTOS-17 : The specification was validated by the CAESAR. ADT compiler, which implements all the syntactic and semantic checks stated in the definition of LOTOS  [19]. The C code generated from the LOTOS specification passed the test vectors specified in  [16, Annexes E. 3. 4 and E. 4 ]. • LNT-17 : The specification was validated by the LNT2LOTOS translator, which implements the syntactic checks and (part of) the semantic checks stated in the definition of LNT  [1]  and generates LOTOS code, which is then validated by the CAESAR. ADT compiler, therefore performing the remaining semantics checks of LNT. The C code generated by the CAESAR. ADT compiler passed the test vectors specified in  [17, Annex A] , in  [16, Annexes E.
Five specifications have been successively developed: LOTOS-92 ,  Retrospectively, heading towards executable formal methods proved to be a successful bet: • It turns out that executable specifications are not necessarily longer than non-executable ones: LNT-17 and LOTOS-17 (345 and 423 lines, respectively, including the external C code fragments) are half way between the non-executable specifications VDM-90 (275 lines) and Z-91 (608 lines). Also, LNT-17 is only 60% larger than the direct implementation in C given in  [4]. • One might argue that the LOTOS and LNT specifications are not entirely formal, as they import a few C types and functions to implement blocks and arithmetic operations on blocks. We see this as a strength, rather than a weakness, of our approach. Moreover, nothing prevents such external types and functions to be instead defined in LOTOS or in LNT, as this was the case with the REC-17 specification, which was then automatically translated to self-contained, fully-formal LOTOS and LNT specifications that were successfully compiled and executed.
• The insight gained by comparing the eight formal specifications of the MAA confirms that LNT is a formal method of choice for modelling complex algorithms and data structures. Compared to other formalisms, LNT offers an imperative specification style (based on mutable variables and assignments) that proved to be simpler to write, easier to read, more concise, and closer to the MAA description in natural language  [4] , from which specifications based on term rewrite systems and abstract data types significantly depart due to picky technical restrictions in these latter formalisms. LNT also favors a more disciplined specification style that, we believe, is of higher quality because of the numerous static-analysis checks (e. g. , unused variables, useless assignments, etc. ) performed by the LNT2LOTOS translator; such strict controls are, to the best of our knowledge, absent from most other specification languages.
Acknowledgements We are grateful to  Philippe Turlier  who, in 1992, helped turning the non-executable LOTOS specification of  Harold B. Munster  into an executable one, to  Wendelin Serwe , who, in 2016, produced the first LNT specification of the MAA, and to  Frédéric Lang , who, in 2016-2017, improved the LNT2LOTOS translator to address the issues pointed out. Acknowledgements are also due to  Keith Lockstone  for his advice and his web site 16 giving useful information about the MAA, and to  Sharon Wilson , librarian of the  National Physical Laboratory , who provided us with valuable early NPL reports that cannot be fetched from the web.
Acknowledgements This work was supported by the  European Research Council   ERC Consolidator  grant  BrightSens 648528 and ANR grant  ( ANR-10-INBS-04 ). The work in the laboratory of LD is supported in part by the  Fédération pour la Recherche sur le Cerveau (FRC)  and the  Rotary. This work has been partially funded by the  Region Ile-de-France  in the framework of DIM ELICIT. We thank  Romain Vauchelles  for his assistance at the PIQ platform,  Pauline Meyer  for the mass measurements,  Bohdan Wasylyk  for providing the KB cells and  Dr. Florence Toti  and  Mohamad Kassem  for providing fresh rat liver tissues. We acknowledge the  ImagoSeine core facility  of the  Institut Jacques Monod , member of  IBiSA  and the  France-BioImaging infrastructure. We thank  Dr. Carl G. Ebeling  ( Worldwide Application Scientist for Bruker Fluorescence Microscopy ) for his help with the use of the Bruker Vutara system and its SRX visualisation and analysis software for rendering localisation data.
We systematically compare critical implementation details and introduce one new generic attack vector which allows bypassing stack canaries on current Linux systems running up-to-date multi-threaded software altogether. We release an open-source framework (CookieCrumbler ) that identifies the characteristics of stack canaries on any platform it is compiled on and we propose mitigation techniques against stack-based attacks. Although stack canaries may appear obsolete, we show that when they are used correctly, they can prevent intrusions which even the more sophisticated solutions may potentially fail to block.
This allows an attacker to overwrite the control-flow relevant data structures and the current reference value at the same time and thereby reliably bypass SSP. In summary, we make the following main contributions: -We propose CookieCrumbler , a framework to automate the identification of the characteristics of SSP implementations. -We evaluate CookieCrumbler against state of the art operating systems and libraries, and discover weaknesses in multiple SSP implementations. -We introduce a novel attack vector to exploit those vulnerabilities. -We propose mitigations techniques to harden SSP implementations.
Attackers may try to evade StackGuard by embedding the canary in the data used during the overflow (i. e. , canary forgery). Cowan et al. [7]  propose two methods to prevent such a forgery: terminator and random canaries. In 32-bit operating systems, a terminator canary is usually constructed using of the char representation of NULL, CR, LF, and EOF (0x000d0aff). This is because overflows often exploit unsafe string manipulation functions: as the terminator canary includes characters which are used to terminate strings, it is impossible to directly include them in a string without terminating the string operation. However, not all buffer overflows are due to unsafe string manipulation operations (e. g. , read()) and the fixed terminator canary does not provide any protection in those cases.
Function Pointer Protection Function pointers stored in writable memory at static addresses are common targets to gain control of a vulnerable program's execution. To defend against this threat,  [7]  introduces code pointer protection. PointGuard  [15]  is the first mechanism capable of encrypting code pointers in memory. For each process, PointGuard generates a random key during process creation. Each pointer in memory is then scrambled in memory by performing a bijective operation on the pointer using the process's specific random key. Glibc implements this protection mechanism since 2005  [16]  by using the PTR _ [DE]MANGLE macros. On the other hand, the Windows run-time, provides similar functionality with the Rtl[En|De]codePointer API call since XP SP2 (2004). Both implementations use very similar algorithms to encipher pointers: a logical bit rotation combined with an xor (⊕) involving the per-process random secret (rand).
For instance, the 64-bit Windows run-time implements the following two equations for pointer protection: ptr enc = ror64(ptr orig ⊕ rand, rand) (1) ptr orig = rol64(ptr enc , rand) ⊕ rand (2) On Linux (with glibc), the situation is very similar, except that a constant is used as the number of digits to rotate (0x11 is actually 2 • sizeof(void * ) + 1): ptr enc = ror64(ptr orig ⊕ rand, 0x11) (3) ptr orig = rol64(ptr enc , 0x11) ⊕ rand (4) Most notably, the main difference in the two implementations is that on Windows the Rtl[En|De]CodePointer retrieves the value rand from the kernel, whereas glibc on Linux stores the pointer guard in user space in the Thread Control Block (TCB). Cowan et al. [15]  state that the PointGuard key has to be stored on its own page once it is initialized to protect the key against information leakage.
Attacks Against Stack Canaries An adversary may attempt to attack the stack canary mechanism itself in order to successfully exploit a program. Strackx et al. [17]  analyze the security promises made by randomization based buffer overflow mitigation systems, such as the ones described above. They conclude that a vulnerable program offering both a buffer overread and a buffer overflow can be easily attacked. However, their work misses the experimental evaluation of the success rate of such an attack. Ding et al. [18]  reveal weaknesses in the StackGuard implementation used in Android 4. 0: the source of randomness used for the stack canaries is only initialized once at OS boot and then used for every application on the system. In addition, the created canary is predictable as the state used to initialize the canary only depends on randomness available at kernel boot-up.
Thread Control Block Modern OSes contain a dedicated data structure, called TCB, to store information about the environment that the current thread is executing in. The data stored in the TCB varies depending on OSes and thread library implementations. For instance, on Windows this data structure is named ThreadInformationtBlock and contains information about a thread's Structured Exception Handling (SEH) chain, its associated Process Control Block (PCB), and a pointer to Thread Local Storage (TLS). The TCB is accessed either using a library function or a designated register that improves speed. For example, glibc on Linux x86_64 uses the fs register as the base address of the TCB. Intel provides Model Specific Register s (MSRs) to override fs and gs segment base addresses, effectively enabling 64-bit OSes to access the TCB in a fast way.
Qualitative Features We identify key features of stack canaries by studying the source code of their implementations-if available-or reverse engineering the functionality in their binary format. Assumption (immediate termination) is another claim that can only be verified in a qualitative manner. To find the quantity of code executed after the canary corruption is detected, we introduce the notion of noisiness of the failure handler. To estimate the Noise level, we count function invocations that are triggered from the point where execution enters the cookie verification failure handler until the point where the application terminated. We also manually check the number of variables that are read from the corrupted memory region (e. g. the stack), and whether the handler executes in user or kernel mode, which we denote by Current Privilege Level (CPL).
Threads are created by calls to the functions pthread _ create (on UNIX) or CreateThread (on Windows). To determine W(∆ x ), we use signal handling on UNIX (catching SIGSEGV on a contiguous byte-by-byte write) and the function IsBadWritePtr on Windows. After successful execution, CookieCrumbler generates a set of memory locations, deltas, and number of writable bytes for the main-and the sub-threads of a threaded application, respectively. A thorough analysis of these results can reveal potential vulnerabilities in the implementation of stack canaries. The source code and the measured data can be found online. 5.