dataesr/scientific-paragraphs-categorization huggingface dataset:
The separator is given by a script parameter. The names of the parameters are given in the sections corresponding to the algorithms. CoclustMod Algorithm All the options available for the CoclustMod algorithm are summarized below: --from=2 minimum number of co-clusters --to=10 maximum number of co-clusters For example, for the CSTR dataset, the best number of co-clusters found by the following command is 4, the same as the real number of clusters: > coclust-nb datasets/cstr. csv --seed=1 --n_runs=30 --max_iter=60 --visu  In this example, the best modularity is 0. 478638 and is attained for 4 co-clusters. The evolution of the modularity against the number of co-clusters is plotted in Figure  3.
CoClustMod usage The following example shows how to load the Classic3 dataset from a MATLAB file. The MATLAB file is loaded using a function provided by the SciPy library. A matrix is then extracted from the MATLAB dictionary and stored in variable X. A co-clustering model with 3 co-clusters is then created, and receives as input the X matrix. Then, after displaying the maximum modularity value as well as its evolution over the iterations, (Figure  4 ), several graphical representations of the obtained term clusters are produced via the plot_cluster_top_terms and get_term_graph functions (Figures  5  and 6 ). The get_term_graph function extracts the n most frequent terms in a given term cluster along with the k most similar (in terms of cosine similarity) neighbors of each of these most frequent terms.
CoClustInfo usage In this example, the Classic3 dataset is imported from a MATLAB file. A model is created and fitted. A graph showing the evolution of the criterion is displayed along with the last γ kl matrix obtained at the end of the execution. This matrix allows to visually spot the most cohesive co-clusters produced by the algorithm (see Figure  8 ). >>> import scipy. io as io >>> from sklearn. metrics import (adjusted_rand_score as ari,. normalized_mutual_info_score as nmi) >>> from coclust. coclustering import CoclustInfo >>> from coclust. evaluation. external import accuracy >>> from coclust. visualization import plot_delta_kl, plot_convergence >>> >>> print("1) Loading data") >>> file_name = "datasets/classic3. mat" >>> matlab_dict = io. loadmat(file_name).
Example of integration with scikit-learn In the following example, the scikit-learn library is used to import the corpus of documents NG20 (see Section 4. 1), select only five categories, and create a document-term matrix. This example shows how easy it is to include an algorithm of the CoClust package in a scikit-learn Pipeline. >>> For a scikit-learn Pipeline, the set_params method takes a variable number of arguments, each of the form component__parameter. In pipeline. set_params(coclust__n_clusters =5), the component corresponding to the modularity co-clustering algorithm is named coclust and the parameter of the class CoClustMod we want to set to 5 is n_clusters.
Description of datasets To assess the performance of the three implemented algorithms, we tested them on 8 datasets of different size, sparsity and balance 6  (see Table  3 ). The characteristics of each dataset are reported in Table  3. -The CSTR dataset was previously used in  (Li 2005)   -SPORTS is a dataset from the CLUTO toolkit  (Karypis 2003) , and is the same as that used in  (Zhong and Ghosh 2005). This dataset contains documents about 7 different sports including baseball, basketball, bicycling, boxing, football, golfing and hockey. -REVIEWS is also a standard dataset used by the CLUTO toolkit. -WEBACE  (Ding and Li 2007)  contains news articles partitioned across 20 different topics obtained from the WEBACE project  (Han, Boley, Gini, Gross, Hastings, Karypis, Kumar, Mobasher, and Moore 1998).
-RCV1 (Cai and He 2012) is a subset of a newswire stories corpus made available by Reuters containing 4 categories: C15, ECAT, GCAT, and MCAT. -Finally, NG20 is the 20 Newsgroups data set. In addition to the three algorithms included in the package (denoted as CoclustMod, Co-clustSpecMod and CoclustInfo in the experiments), we also included in the comparison the implementations of the two co-clustering algorithms available in scikit-learn, denoted as SpectralBi and SpectralCo in our experiments. 9.
12 The datasets and benchmark code can be found in the benchmark directory of the package. 13 In these tables the number of row and column clusters requested is specified within parentheses after the dataset name. by the coclust-nb script described in Section 3. 1). There, is however a marked difference in execution time between CoclustInfo and CoclustMod. A drawback of CoclustMod is that it has to handle a non sparse, modularity matrix, which is both time and memory consuming. As a consequence, in terms of execution time, CoclustMod is the slowest of the five compared algorithms. In contrast, the implementations available in scikit-learn are very fast but, as already said, have significantly lower accuracy and NMI scores.
Conclusion Co-clustering is an important technique in the era of so-called "big data" since it allows to compress large, high dimensional matrices. However, few tools were available so far for the Python community, and the CoClust package, therefore, aims at filling this gap. By presenting and contrasting the theory and implementation of two distinct families of coclustering algorithms (block-diagonal and non diagonal algorithms). The paper also provides the reader with a representative survey of methods available in the co-clustering field. Experimental results show that the three implemented algorithms adapt well to datasets of various balance and sparsity and can be used with good co-clustering performance in many settings. In particular, they clearly outperform the available Python implementations of coclustering algorithm in terms of result quality.
To measure the impact of the hash function, we aim to measure the performance of the whole offline cracking process, which is composed of the candidate generation by an enumeration algorithm, the candidate hashing and the search for its fingerprint in the targeted dataset. The performance on a period of time is defined as the number of found passwords in that period. The most popular academic enumerators categories are Probabilistic Context-Free Grammars (PCFG)  [15, 28, 30]  and Markov chains models  [9, 16, 18]. These models are probabilistic, as they assign probabilities to passwords to measure their strength, whereas very fast enumerators are also implemented in free software like John The Ripper (JtR)  [21]  and Hashcat  [24]. These enumerators are optimized for their runtime performance.
-Experiments on leaked databases with this performance measurement show that fast cryptographic hash functions are unsuitable for password storage, because even the most naive strategies (like bruteforce) perform very well against them. They also show that academic enumerators are very useful against slow hash functions. To make them even more performing, developers should implement them in their password cracking tools. This paper is organized as following. First, we present the background and related works 2. Then we introduce our password cracking modelling 3. In section 4 we explain how we compute the performance using success rate and frequency measurements. Section 5 contains the results of performance measurements on two publicly leaked passwords using two different hash functions. Then, in section 6, we expose different scenarios in where our work has concrete interests.
Enumerators Several enumerators have been proposed by academic researches, but few are currently implemented in the most well-known password cracking software. For example, John The Ripper and Hashcat include a Markov model-based enumerator that has been originally introduced in  [18]. However, the remaining proposed enumerators are distributed in standalone versions, meaning they are not actually cracking passwords. Instead, they only generate candidates that might be actual passwords. These candidates should then be gathered by a password cracking software to do the rest of the process: hash them and search for a match. Bruteforce: this is the most naive and the most known enumerator. Basically, bruteforce will output the words incrementing the characters one by one using a defined alphabet.
In this paper, we run our own C implementation of the bruteforce algorithm. Markov Models: they are probabilistic models that can be applied to words, for which the probability of a character at a given position depends on the previous characters. The software will learn probabilities on a dataset and will then output newly-created words according to these probabilities. In this paper, we consider two enumerators based on Markov models implementations: John The Ripper's Markov mode  [1]  and OMEN  [8]. The main differences between them is that OMEN outputs candidates in approximately decreasing probabilities order. Also, OMEN has an adaptive strategy which reorders the sets of next candidates based on the success rate of previous ones. Probabilistic Context-Free Grammars: Weir et al. [30]  are the first to use PCFGs for passcracking.
Kelley et al. and Komanduri [13]   [15]  have modified Weir's PCFGs by adding string tokenization and by assigning probabilities to terminals that have not been seen in the training dataset. The implementation used in this paper is the Weir's one and can be found on Github  [29]. For easier reading, we will write "PCFG" referring as the Weir et al. algorithm. In this paper, we make use of these four enumerators: bruteforce, JtR-Markov, OMEN and PCFG. They only generate candidates as they do not hash them or search for them in the targeted database. We don't make use of Hashcat and John The Ripper password cracking features, only the Markov-based enumerator of John The Ripper.
Attackers are then forced for each candidate to apply the salt value before hashing, slowing down the speed of the attack and making pre-computation-based attacks  [11, 20]  impracticable. The leaked databases on which we experiment in this paper are not salted. Nevertheless, our model still apply since we don't use pre-computed tables and usage of a salt multiply the cost of the attack by the number of users. Password-specific hash functions like bcrypt  [23] , Scrypt  [22]  or Argon2  [4] , winner of the Password Hashing Competition  [3] , have been proposed to replace fast hash functions. They are designed to break the usage of massive parallel processing units by requiring a big memory and time amounts to compute one hash. Moreover, they handle themselves the salt value, making easier for developers to manage and store passwords.
In this paper we consider two hash functions: the first, SHA-1, due to its wide usage according to publicly leaked passwords datasets (especially in Linkedin). SHA-1 will represent the set of cryptographic hash functions (MD5, SHA-1, SHA2, SHA-3,. ), since these functions are similar for our study. The second is bcrypt, the reference function to store passwords, with a cost factor of 10 which is the default cost factor for PHP's password hash() function at the time of writing. Since Argon2, Scrypt and bcrypt are for our study very similar, we only consider bcrypt since it is more commonly used than Argon2 and Scrypt.
Datasets Here are presented the publicly accessible datasets used in this paper. Note however that there exists many more datasets that can be used for such a study. The ones we used are enough to illustrate our modelling, as it does not aim to be exhaustive. Further works can be conducted on more datasets. A list of recent leaks can be found at  [12]. Rockyou: The most used dataset, probably because in plaintext and easily accessible. Rockyou is a company providing services to social networks and video games. The leak happened in 2009. It contains more than 32 million of passwords (14 million unique). LinkedIn: This leak comes from the LinkedIn social network. The hack happened in 2012. Four years later, the entire database were published, containing more than 160 million of passwords (60 million unique).
Context The cracking process, at the level of a single candidate, can be resumed in 3 steps: (i) generate a candidate (ii) hash it (iii) search for a match in the target database In practice, searching for a match in step (iii) is negligible, even when a fast hash function is used. Indeed, most password cracking tools use a probabilistic structure, similar to a Bloom filter with only one hash function, to store the hashed passwords list in memory. We assume that step (iii) takes no time. Then according to the hash function in step (ii), the bottleneck of the process is either step (i) or (ii).
Formalization of the Performance Even if in practice we compute a discrete version of this password cracking process, it remains a continuous process since the time is continuous, which explains the usage of integrals. Let first consider the performance at the level of a single candidate. For any i ∈ N, let t i be the instant where we finish to process the i th candidate of the enumeration, g i the gain of this candidate, i. e. its number of occurrences in the dataset D and c i the time to process it (steps (i), (ii), (iii)), i. e. c i = t i -t i-1. The performance will be P (t i-1 , t i ) = g i. Thus P (t i-1 , t i ) = c i g i c i = t i t i-1 g(t) c(t) dt, where c(t) = c i and g(t) = g i. Note 1. this model includes the parallelization of the process, since g(t) and c(t) could be measured on multiple cores.
For example, in average, PCFG generates ≈ 8 × 10 4 candidates per second, OMEN 10 6 , JtR-Markov 2 × 10 7 and bruteforce 1. 6 × 10 9 (note however that these times are not constant during enumeration, hence are presented here to have a glance on enumerators speed). In our experiments, we chose N such that times required to generate N candidates are about 0. 1 second (at beginning) to have both a good estimation of C(t) and an acceptable number of floating point numbers to store. Our values of N for each enumerator can be found in Table  1. Success rate measurement. To measure the success rate, we want to have for each candidate, its rank and its gain (how many times it appears in the dataset). There are two ways of measuring the success rate: by running the enumerator and counting occurrences in the dataset, or backwardly by computing for each password of the dataset, its rank in the enumeration if the enumerator has an index function.
Experimental Results In this section we present the experiments of the performance computation for four enumerators, the bruteforce, John The Ripper-Markov mode, OMEN and the PCFG-based enumerator, over the datasets LinkedIn and Rockyou, and using two hash functions, SHA-1 and bcrypt (cost 10). To be able to compare plots with previous researches and across datasets, rather than plotting the performance, we plot the percentage of cracked passwords from the beginning. We can then compare how they perform between each other over time and across datasets. We still took  [10]  for hash functions benchmarks. For SHA-1, 1/c h ≈ 12. 5 × 10 9 , and for bcrypt with a cost of 10, which is the default cost factor for PHP's password hash() function at the time of writing, 1/c h ≈ 700. Note that the benchmarks in Hashcat uses a cost 5 bcrypt, which means 2 5 rounds of the internal key-derivation function.
Thus, c h for a cost-10 bcrypt is 2 5 times smaller, giving 23 × 10 3 /2 5 ≈ 700. On Figure  2 , showing how enumerator perform over LinkedIn with the SHA-1 function, JtR-Markov and PCFG cracked about 60% of passwords after four hours, while OMEN cracked around 43% and the bruteforce around 36%. Bruteforce, even though it is the most naive method, still has good results. PCFG is surprisingly good since it exploits the high number of passwords sharing the same grammatical structure in this dataset: 37% of passwords share the top five most frequent structures. However using bcrypt (Fig. 3 ), enumerators performances are completely disrupted. Because of the poor quality candidates of the bruteforce, the whole process spends its time to hash candidates which give mediocre success rates. After four hours, bruteforce cracked less than 1% of the dataset, while PCFG still performed great by cracking 43% of passwords.
OMEN is better placed than before, cracking more than 18% of the dataset. Finally, JtR-Markov is worse than OMEN, finding only 11% of passwords after four hours. On Rockyou using SHA-1 (Fig. 4 ), JtR-Markov cracked 15% passwords more than on LinkedIn after four hours, while OMEN cracked 23% more than on LinkedIn, and the bruteforce 12% more. However, PCFG perform similar than on LinkedIn using SHA-1. On Rockyou using bcrypt (Fig. 5 ), results are similar than with LinkedIn using bcrypt: even though enumerators cracked not the same number of passwords, their performances are in the same order. The "steps" of the OMEN curves on all figures is due to the fact that it generates sets of candidates of same length. When OMEN switches the length of the candidates, it suddenly cracks many more passwords.
These four graphics highlight the impact of the hash function concerning the performance of the cracking process. They confirm our hypothesis that hacker enumerators are well-performing using fast hash functions while academic enumerators perform better using slow hash functions. One special mention to the PCFG-based enumerator which performs quite well on LinkedIn using SHA-1. Finally, experiments on each dataset can be easily adapted to other hash functions or to other parameters, like the cost of bcrypt. We could also choose the algorithm depending on the used hash function from the beginning. With the rise of memory-hard functions usage like bcrypt or Argon2, it will be even more interesting to have software-optimized academic enumerators implemented in password cracking tools. It is important to note that the performance of enumerators highly depends on the dataset, and that OMEN becomes better than PCFG when attacking more complex datasets where passwords are longer and having more complex structures, like when keeping only strong passwords (longer than 8 characters, include all four characters classes).
Furthermore, since you independently measured success rate and frequencies during a cracking session, you can independently analyze the behaviors of the success rate or the frequency during the enumeration. Thanks to that, you have a clearer understanding on your enumerator performance. Then you are able to propose different enumerators settings regarding the attacked dataset. If your measurements show that a set of parameters provides good results against a given dataset, you can be pretty confident that this set of parameters will also provides good results against a similar dataset (for example where the password composition policiy is similar). Moreover, you can implement a strategy in your enumerator that adapt the enumerator settings depending on the found passwords. For example, if you found a lot of passwords of length 6, your enumerator can for a while only generate passwords of length 6.
Password cracking tools developers. Imagine once again a scenario where you are a developper of a password cracking tool and want to implement and optimize better enumerators in your tool. Using our comparison methodology, you are able to compare existing enumerators as if they were integrated in your software. For example, on both attacked datasets in section 5, PCFG is not really impacted when using bcrypt instead of SHA-1. Implementing it directly in your cracking tool would make it even more efficient in such contexts. Therefore, based on the hash function used in the targeted dataset, your tool can select different enumerators at the beginning of the cracking session. You can select those which are known to be more efficient against fast hash functions when you detect such functions, and similarly for slow hash functions.
The results of our research emphasize on the importance of a good hash function to protect passwords. Cryptography-oriented hash functions are unsuitable for password hashing since they allow to most of attacks to be very efficient even if their success rate is low. Therefore, it is essential for you to protect passwords using a dedicated hash function that has been designed for it, like bcrypt or Argon2d. Nevertheless speed performance of the hash function also depends on the hardware  [14]. Dedicated hardware (ASIC or FPGA) focuses particularly on hash functions used in cryptocurrencies mining (typically SHA-256 but also Scrypt)  [2]. Nonetheless, the results also show that a slow hash function is not enough to offer a very good protection for passwords. For example, PCFG still perform well against bcrypt-protected datasets.
Conclusion Our study proves the importance of the speed of the enumerator and the hash function in the performance measurement of a password cracking process. Thanks to that, it becomes possible to evaluate how efficient a slow memory-hard function is against the different enumeration strategies of the literature. Even if we observe an increase of the bcrypt and Argon2d usage, recent passwords database leaks still confirm the high usage of cryptographic hash functions like SHA-1 and its siblings. We recommend the usage of dedicated slow and memory-hard hash functions to protect passwords. We bring the technical challenges out when computing the performance of enumerators in password cracking context. Firstly, we highlight the impossibility to compute both the number of found passwords and the time to generate the required candidates without altering their values.
In OMEN paper  [9] , authors showed that it was better than PCFG on the Rockyou dataset. However we show that considering the cost of generating candidates, PCFG becomes better in all presented experiments. We showed that JtR-Markov is really relevant when using a fast hash function like SHA-1, while probabilistic enumerators like OMEN and PCFG-based algorithms perform better than others using slow hash function like bcrypt. If PCFG and OMEN were optimized for password cracking, results would change only against fast hash functions, where OMEN, PCFG and JtR-Markov would be more distinguishable. We encourage Hashcat and John The Ripper developers to implement such algorithms in further versions of their tools. Hashcat developers have already took a step in that way since the version v5. 0. 0 by introducing the feature "slow candidates" which aims to facilitate the integration of slow enumerators proposed by academics.
Introduction The LHCb experiment  [1]  has recorded since 2013 data in various configurations in addition to the pp collisions on which its main physics program is based. These configurations are collisions of protons with lead ions (pPb) at a center-of-mass energy per nucleon pair of 5 TeV in 2013 and 2016, and of 8. 16  TeV in 2016, and collisions of lead beams (PbPb) at a center-of-mass energy of 5 TeV in 2015. Fixed-target collisions are also possible at the LHCb interaction point, and have been recorded with the detector. They are obtained thanks to the SMOG (System for Measuring Overlap with Gas) device  [2, 3] , which can inject gas into the LHC vacuum at the LHCb interaction point. Since 2013, data have been collected with several types of gases: Ne, Ar and He, and both types of LHC beams, p and Pb.
Simulation of minimum bias heavy-ion or fixed-target collisions in the Gauss framework The generation of events uses the same features as for the generation of pp collisions  [14]. The sequence is composed of 4 steps described below. Each step corresponds to a generic algorithm which is configured to match the heavy-ion or fixed-target behaviour via Python steering files. These generic algorithms are originally developed for the generation of pp collisions in Gauss and can be re-used without modification.