Authors:
(1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu);
(2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd);
(3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd);
(4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu);
(5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu);
(6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu);
(7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu);
(8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Table of Links Abstract and 1 Introduction 2 Overview of MASC 3 Design Goals 4 Implementation of MASC 4.1 Mutation Operators 4.2 Mutation Scopes 5 Using MASC 6 Future Work and Conclusion, Acknowledgments, and References 3 DESIGN GOALS We considered several goals while designing MASC, while leaning on the experience we gained from the original version. Diversity of Crypto-APIs (DG1): Effectively evaluating crypto-detectors requires considering misuse cases of existing crypto-APIs, which is challenging as crypto-APIs are as vast as the primitives they enable. To address this, the crypto-API mutation operators need to be decoupled from the crypto-APIs. Such implementation would mean that even in the case when new crypto APIs are introduced, MASC can still create mutated misuse cases as long as the new crypto-APIs follow existing design principles. Open to Extension (DG2): While both original and current implementations of MASC come with 12 generalizable mutation operators, these represent a subset of different expressions of misuse cases. Hence, MASC should be open to extension by stakeholders so that they can create their own mutation operators that can be easily plugged-in to MASC, without needing to modify MASC. Ease of Evaluating Crypto-detectors (DG3): While the original, semiautomated implementation of MASC required manual evaluating the target crypto-detector, such heavy-lifting manual effort can not be simply expected from end-users. Part of this manual effort was unavoidable due to the unique, varied outputs produced by cryptodetectors. However, with the recent focus on using crypto-detectors with CI/CD pipelines and the introduction of the de-facto SARIF [15] formatted outputs, it would become possible to not only automate the entire evaluation process, but also make it customizable. Adapting to Users (DG4): Finally, MASC should be created in such a way that it is usable by users of varying skills and in different environments. For instance, it should be usable as a stand-alone binary in a windowless server environment as a component, and as a front-end based software that can leverage the binary of itself. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. Authors: (1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu); (2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd); (3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd); (4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu); (5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu); (6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu); (7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu); (8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Authors: Authors: (1) Amit Seal Ami, Computer Science Department, William & Mary Williamsburg, Virginia, USA, and this author contributed equally to this paper (aami@wm.edu); (2) Syed Yusuf Ahmed, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1013@iit.du.ac.bd); (3) Radowan Mahmud Redoy, Institute for Information Technology, University of Dhaka Dhaka, Bangladesh, and this author contributed equally to this paper (bsse1002@iit.du.ac.bd); (4) Nathan Cooper, Computer Science Department, William & Mary Williamsburg, Virginia, USA (nacooper01@wm.edu); (5) Kaushal Kafle, Computer Science Department, William & Mary Williamsburg, Virginia, USA (kkafle@wm.edu); (6) Kevin Moran, Department of Computer Science, University of Central Florida Orlando, Florida, USA (kpmoran@ucf.edu); (7) Denys Poshyvanyk, Computer Science Department, William & Mary Williamsburg, Virginia, USA (denys@cs.wm.edu); (8) Adwait Nadkarni, Computer Science Department, William & Mary Williamsburg, Virginia, USA (apnadkarni@wm.edu). Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Overview of MASC 2 Overview of MASC 3 Design Goals 3 Design Goals 4 Implementation of MASC 4 Implementation of MASC 4.1 Mutation Operators 4.1 Mutation Operators 4.2 Mutation Scopes 4.2 Mutation Scopes 5 Using MASC 5 Using MASC 6 Future Work and Conclusion, Acknowledgments, and References 6 Future Work and Conclusion, Acknowledgments, and References 3 DESIGN GOALS We considered several goals while designing MASC, while leaning on the experience we gained from the original version. Diversity of Crypto-APIs ( DG1 ): Effectively evaluating crypto-detectors requires considering misuse cases of existing crypto-APIs, which is challenging as crypto-APIs are as vast as the primitives Diversity of Crypto-APIs DG1 they enable. To address this, the crypto-API mutation operators need to be decoupled from the crypto-APIs. Such implementation would mean that even in the case when new crypto APIs are introduced, MASC can still create mutated misuse cases as long as the new crypto-APIs follow existing design principles. Open to Extension ( DG2 ): While both original and current implementations of MASC come with 12 generalizable mutation operators, these represent a subset of different expressions of misuse cases. Hence, MASC should be open to extension by stakeholders so that they can create their own mutation operators that can be easily plugged-in to MASC, without needing to modify MASC. Open to Extension DG2 Ease of Evaluating Crypto-detectors ( DG3 ): While the original, semiautomated implementation of MASC required manual evaluating the target crypto-detector, such heavy-lifting manual effort can not be simply expected from end-users. Part of this manual effort was unavoidable due to the unique, varied outputs produced by cryptodetectors. However, with the recent focus on using crypto-detectors with CI/CD pipelines and the introduction of the de-facto SARIF [15] formatted outputs, it would become possible to not only automate the entire evaluation process, but also make it customizable. Ease of Evaluating Crypto-detectors DG3 Adapting to Users ( DG4 ): Finally, MASC should be created in such a way that it is usable by users of varying skills and in different environments. For instance, it should be usable as a stand-alone binary in a windowless server environment as a component, and as a front-end based software that can leverage the binary of itself. Adapting to Users DG4 This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. This paper is available on arxiv under CC BY-NC-SA 4.0 DEED license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

MASC Design Goals: Extensibility, Diversity, and Usability in Crypto-Detection

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A Comprehensive Comparison of Tools for Fitting Mutational Signatures

Crypto APIs' Role within Blockchain as a Service (BaaS)

How to Import Crypto APIs into Excel

The 5 Best Cryptocurrency Data APIs in 2022

Top 5 Crypto APIs for Developers

The #crypto-api Writing Contest by CoinGecko and HackerNoon

A Comprehensive Comparison of Tools for Fitting Mutational Signatures

Crypto APIs' Role within Blockchain as a Service (BaaS)

How to Import Crypto APIs into Excel

The 5 Best Cryptocurrency Data APIs in 2022

Top 5 Crypto APIs for Developers

The #crypto-api Writing Contest by CoinGecko and HackerNoon

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps