Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
177
datasets available to search
ShareScore release 0.9.0
Dataset results
177 results for “Research tool”
MiRoR15-P2-Development of ARCADIA: a tool for assessing the quality of peer-review reports in biomedical research
<p>Survey questionnaire, anonymised survey data, and codebook related to: Superchi C, Hren D, Blanco D, Rius R, Recchioni A, Boutron I, González JA. Development of ARCADIA: a tool for assessing the quality of peer-review reports in biomedical research. BMJ Open 2020;0:e035604. doi:10.1136/bmjopen-2019-035604</p>
Multi-stakeholder research data management training as a tool to improve the quality, integrity, reliability and reproducibility of research: Quantitative data of the post-course surveys
<p>Data contains doctoral students' and postdoc researchers' (n=168) self-ratings of their RDM competencies before and after the 3 ECTS credits "Basics of Research Data Management" (BRDM) trainings held 2019-2021 in the University of Turku and Åbo Akademi University, Finland. Moreover, data contains respondents' self-reported further learning needs.</p>
From A to Z: Projective coordinates leakage in the wild: research data and tooling
<p>Description</p> <p>This dataset and software tool are for reproducing the research results related to CVE-2020-10932 and CVE-2020-11735, resulting from the article "From A to Z: Projective coordinates leakage in the wild" (to appear at CHES 2020). The data was used to carry out the attack in Section 6 of the article.</p> <p>Data format</p> <p>txt files</p> <p>The <code>[int].txt</code> files contain an encoded page-fault trace prefixed by <code>trace:</code>.</p> <p>A trace represents the sequence of tracked memory pages that were executed during the generation of an ECDSA signature. The trace is encoded using ASCII characters for better visualization.</p> <p>The encoding follows this table:</p> <pre><code class="language-markdown">| Functions | Symbol | Page offset | | ---------------------- |:------:|:-------:| | _gcry_ecc_ecdsa_sign | T | 0xa1000 | | _gcry_mpi_invm | . | 0xcf000 | | _gcry_mpi_set | S | 0xd5000 | | _gcry_mpi_add | A | 0xcd000 | | _gcry_mpih_sub_n | - | 0xd8000 | | _gcry_mpih_rshift | - | 0xd8000 |</code></pre> <p><code>_gcry_ecc_ecdsa_sign</code> is the highest level function tracked in the attack. This allows to differentiate different calls to the <code>_gcry_mpi_invm</code> function which contains an insecure version of a Binary Extended Euclidean Algorithm (BEEA).</p> <p>Using these pages it is possible to locate the execution of <code>_gcry_mpi_invm</code> corresponding to the computation of <code>Z mod p</code> during projective to affine coordinates conversion (see <code>preprocess_trace</code> function).</p> <p>It can be seen, that <code>_gcry_mpih_sub_n</code> and <code>_gcry_mpih_rshift</code> shares a page. However, they can be differentiated using mainly the caller memory page. This sharing, instead of being a drawback, allows a straightforward recovery of BEEA execution flow (see <code>extract_Zi</code> and <code>extract_Xi</code> functions in <code>recover_z.py</code>).</p> <p>dat files</p> <p>The format of the <code>[int].dat</code> files is as follows.</p> <ul> <li><code># X [hex]</code>: Ground truth projective output of scalar multiplication, before affine conversion</li> <li><code># Y [hex]</code>: Ground truth projective output of scalar multiplication, before affine conversion</li> <li><code># Z [hex]</code>: Ground truth projective output of scalar multiplication, before affine conversion</li> <li><code># curve_name [str]</code>: The curve (P256)</li> <li><code># h [hex]</code>: Hash of the message to be signed</li> <li><code># k [hex]</code>: Ground truth ECDSA nonce</li> <li><code># q [hex]</code>: Curve order</li> <li><code># r [hex]</code>: First component of the ECDSA signature</li> <li><code># s [hex]</code>: Second component of the ECDSA signature</li> <li><code># x [hex]</code>: Ground truth ECDSA private key</li> <li><code># y [hex] [hex]</code>: Public key coordinates</li> <li><code># leak_pad [int],[int],[int]</code>: Leakage recovered during backtracking. Example: <code>0,4,15 => 0 = k % 2**4 = k & 15</code></li> </ul> <p>Tooling</p> <p>The <code>recover_z.py</code> script</p> <ul> <li>Loads a trace.</li> <li>Recovers the corresponding Z coordinate from the trace data.</li> <li>verifies the recovered Z matches the ground truth Z.</li> </ul> <p>Example</p> <p>Unpack the data:</p> <pre><code>tar xf traces.tar.gz</code></pre> <p>Run the tooling on trace index 123:</p> <pre><code>$ python2 recover_z.py 123 INFO:recovered Z:65b9b7006bc7b030218bef1b6e569f9f7acaee059b53d669388c6b860f67e213 INFO: real Z:65b9b7006bc7b030218bef1b6e569f9f7acaee059b53d669388c6b860f67e213</code></pre> <p>The output demonstrates the recovered Z coordinate is correct, i.e. matches the ground truth.</p> <p>Credits</p> <p>Authors</p> <ul> <li>Alejandro Cabrera Aldaya (Tampere University, Tampere, Finland)</li> <li>Cesar Pereida García (Tampere University, Tampere, Finland)</li> <li>Billy Bob Brumley (Tampere University, Tampere, Finland)</li> </ul> <p>Funding</p> <p>This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 804476).</p> <p>License</p> <p>This project is distributed under MIT license.</p> <p> </p>
EnrichKit: a multi-omics tool for livestock research
<p>This is the backend database for the web application EnrichKit.</p> <p>This <a href="../api/records/10257552/draft/files/EnrichKitDB.sqlite/content">EnrichKitDB.sqlite </a>object is created following this repo - https://github.com/liulihe954/EnrichKitDB</p> <p>The main EnrichKit repo can be found there - https://github.com/liulihe954/EnrichKitWeb</p>
MastaBase: a research tool for the study of 'daily life' scenes in Old Kingdom elite tombs
<p><em>Mastabase: a research tool for the study of the secular or 'daily life' scenes and their accompanying texts in the elite tombs of the Memphite area in the Old Kingdom</em></p> <p>The Leiden Mastaba Project was initiated in 1998 to develop a coherent database of iconographic programmes in Old Kingdom elite tombs from the Memphite area (c. 2600-2150 BCE). It was published as a CD-ROM in 2008 by Peeters Publishers in Leuven.</p> <p>The project was directed by dr. René van Walsem at Leiden University, and partly funded by NWO and LUF/Gratama. Hans van den Berg and drs. Marije Vugts played a vital role in its development.</p> <p>The ISO was uploaded by Nicky van de Beek.</p> <p>Project page: https://digitalegyptology.org/mastabase/</p> <p>---</p> <p>The Leiden Mastaba Project (LMP) concerns an integral and analytic study of the secular or 'daily life' scenes and their accompanying texts in the elite tombs of the Memphite area in the Old Kingdom (c. 2600-2150 B.C.). The project has the aim to get insight in the developments of number, size, internal organization and shape of the various (sub)themes, their location in the tomb, their wall position (upper/middle/lower level), and their orientation (north/east/south/west) on the walls. This reflects the dynamics of Old Kingdom funerary culture in general aspects (collective) and in specific cases (individual). Simultaneously it reveals possible local variations, mainly among the large necropoleis of Saqqara and Giza.</p> <p>The data are digitized in a database called MastaBase, published on this cd-rom. Thanks to the standardisation of the material offered in the MastaBase, with this cd-rom it is now possible to gain quick oversights into various different aspects of these tombs and their decoration via extensive selection procedures.</p>
How to Ensure Researchers Share Their FAIR Data: Practical Tips and Tools [Online Workshop, Recording]
<p>The online hands-on workshop was aimed at trainers and support staff covering critical elements of data sharing and available tools and resources for supporting Open Science including:<br> • Open Science resources and Data Management Planning<br> • Consent and Ethical considerations<br> • Legislation and Licence frameworks<br> The objectives of the workshop were i) to raise awareness of key tools and resources available for Open Science training ii) to enable a platform to exchange ideas regarding key training topics and iii)n to provide training materials and worksheets for future reuse.<br> The workshop consisted of presentations, demos, a roundtable discussion on ethical considerations, a showcase of licence frameworks at different European archives and an exercise with all participants fostering an exchange of experiences focused on learnt lessons.</p> <p>The video is available on<a href="https://www.youtube.com/watch?v=uztTCRFRZHg"> the CESSDA Training YouTube channel</a>.</p>
CVE-2019-18222: research data and tooling
<p>This dataset and software tool are for reproducing the research results related to CVE-2019-18222.</p> <p>Description</p> <ul> <li><code>enum</code> contains the key enumeration tool.</li> <li><code>kt_candidates</code> contains the JSON for blinded nonce candidates, indexed by trial number. JSON fields:</li> </ul> <ol> <li><code>kt_candidates</code>: list of nonce candidates.</li> </ol> <ul> <li><code>sig_data</code> contains the JSON for ECDSA signatures, index by trial number. JSON fields:</li> </ul> <ol> <li><code>p</code>: the prime the curve is defined over. (P-256 here.)</li> <li><code>Gx</code>, <code>Gy</code>: Generator coordinates.</li> <li><code>d</code>: Ground truth ECDSA long term key.</li> <li><code>Px</code>, <code>Py</code>: Public key coordinates.</li> <li><code>h</code>: SHA-256 digest to sign, encoded to the finite field.</li> <li><code>k</code>: Ground truth ECDSA nonce.</li> <li><code>r</code>, <code>s</code>: ECDSA signature.</li> </ol> <p>Build</p> <pre><code>cd enum make clean make</code></pre> <p>Run</p> <p>Start with <code>enum</code> as the working directory.</p> <pre><code>cd enum</code></pre> <p>Pull out a <code>kt</code> candidate, in this example index 847.</p> <pre><code>$ jq '.kt_candidates' ../kt_candidates/kt_candidates_847.json [ "0x48ad7217d10f6c7b1a3db836d38aa3972999115f38a6b3d176fc660941aa5c882d2528ec1fc27da7610e7ee3d7dd84367c380259e0386224c2c46aa2a5eb2a0" ]</code></pre> <p>Factor that candidate.</p> <pre><code>$ time sage -c "print ecm.factor(0x48ad7217d10f6c7b1a3db836d38aa3972999115f38a6b3d176fc660941aa5c882d2528ec1fc27da7610e7ee3d7dd84367c380259e0386224c2c46aa2a5eb2a0)" [2, 2, 2, 2, 2, 3, 353, 193243, 1540830719, 9263081209, 103633959617085683, 151389566295160172521, 283135469779419532841, 572987990320782777757565685333349772719941819448953457732874126833] real 0m5.837s user 0m5.648s sys 0m0.214s</code></pre> <p>Now pull out the <code>r</code> component of the ECDSA signature for that index, and convert it from hex to base 10.</p> <pre><code>$ jq '.r' ../sig_data/sig_data_847.json "0x30e2ce20a8140177a31a66763d85f431acc9790dd050ffc22ed5d454cdfbbb67" $ python -c "print 0x30e2ce20a8140177a31a66763d85f431acc9790dd050ffc22ed5d454cdfbbb67" 22111746808803128586382711090186612204136854333384650261207856620766542674791</code></pre> <p>Now run the <code>enum</code> tool to recover the nonce.</p> <pre><code>$ ./enum Usage: ./enum <jobs_num> <jobs_id> <target_base_10> space delimited flat list of factors in base ten</code></pre> <p>The <code><jobs_num></code> and <code><jobs_id></code> arguments are to ease parallel execution; read the source code. But for a single core, pass them as <code>1 0</code>.</p> <pre><code>$ ./enum 1 0 22111746808803128586382711090186612204136854333384650261207856620766542674791 2 2 2 2 2 3 353 193243 1540830719 9263081209 103633959617085683 151389566295160172521 2831354697794195 32841 572987990320782777757565685333349772719941819448953457732874126833 INFO:target:30E2CE20A8140177A31A66763D85F431ACC9790DD050FFC22ED5D454CDFBBB67 INFO:found:31A52C4960857E6D2F7AD82BAC7D55CE6CC9AD13B959F069002B6A949EA6A048 INFO:tests:7879</code></pre> <p>where <code>221..791</code> is the base-10 <code>r</code> component of the ECDSA signature, and <code>2 2 .. 572..833</code> is the full list of blinded nonce factors. In the output:</p> <ul> <li><code>INFO:target:<hex></code> is the hex form of base-10 target input (ECDSA <code>r</code> component).</li> <li><code>INFO:found:<hex></code> is the hex form of the recovered ECDSA nonce.</li> <li><code>INFO:tests:<num></code> is the number of tested nonce candidates (scalar multiplications).</li> </ul> <p>We can see this successfully recovered the nonce (hence long term ECDSA private key) correctly:</p> <pre><code>$ jq '.k' ../sig_data/sig_data_847.json "0x31a52c4960857e6d2f7ad82bac7d55ce6cc9ad13b959f069002b6a949ea6a048"</code></pre>
CVE-2020-12399: research data and tooling
<p>This dataset and software tools are for reproducing the research results related to <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-12399">CVE-2020-12399</a>, resulting from the manuscript "Déjà vu: Side-channel analysis of Mozilla's NSS", to appear at <a href="https://www.sigsac.org/ccs/CCS2020/">ACM CCS 2020</a>.</p> <ul> <li>The data is from a remote timing attack against the NSS v3.51 implementation of DSA signing.</li> <li>The client machine was a 3.1 GHz 64-bit Intel i5-2400 CPU (Sandy Bridge).</li> <li>The server machine was a Raspberry Pi 3 Model B plus board containing a 1.4 GHz 64-bit quad-core Cortex-A53 processor.</li> <li>The client and server were connected by a Cisco 9300 series enterprise switch over Gbit Ethernet.</li> <li>The data contains pow(2,18) samples.</li> <li>The data was used to produce Figure 1 in the paper and contains all the remote timing attack data from Section 4.</li> </ul> <p>Data description</p> <p>The file <code>remote_timings.json</code> contains a single JSON array. Each entry is a dictionary representation of one digital signature. A description of the dictionary fields follows.</p> <ul> <li><code>p</code>: prime (DSA parameter).</li> <li><code>q</code>: generator order (DSA parameter).</li> <li><code>g</code>: generator (DSA parameter).</li> <li><code>x</code>: the DSA private key.</li> <li><code>y</code>: the corresponding public key.</li> <li><code>r</code>: first component of the DSA signature.</li> <li><code>s</code>: second component of the DSA signature.</li> <li><code>k</code>: the ground truth nonce generated during DSA signing.</li> <li><code>k_len</code>: the ground truth number of bits in said nonce.</li> <li><code>msg</code>: message digitally signed.</li> <li><code>h</code>: SHA-256 hash of said message. (Truncated to the same bitlen as q.)</li> <li><code>id</code>: ignored.</li> <li><code>latency</code>: the measured wall clock time (CPU clock cycles) to produce the digital signature.</li> </ul> <p>Prerequisites</p> <pre><code>sudo apt install openssl python3-ijson xxd jq</code></pre> <p>Data setup</p> <p>Extract the JSON:</p> <pre><code>tar xf remote_timings_rpi.tar.gz</code></pre> <p>Key setup</p> <p>Generate the public key (<code>public.pem</code> here) from the provided private key (<code>private.pem</code> here):</p> <pre><code>$ openssl pkey -in private.pem -pubout -out public.pem</code></pre> <p>Examine the keys if you want.</p> <pre><code>$ openssl pkey -in private.pem -text -noout $ openssl pkey -in public.pem -text -noout -pubin</code></pre> <p>Example: Verify key material</p> <pre><code>$ openssl pkey -in private.pem -text -noout Private-Key: (2048 bit) priv: 1f:87:68:eb:57:e1:f4:f1:29:a6:c8:ca:03:c8:db: 49:1d:8e:2b:81:bd:72:92:64:0c:1c:d6:6d pub: 00:9d:fa:bc:47:00:cb:11:fa:51:45:c1:bd:b1:88: 2d:dd:a2:79:5b:c3:43:0a:af:bb:83:e2:d5:84:d1: 07:01:ab:f9:ae:76:2d:dd:f2:a5:75:f5:3e:94:4d: 3b:c6:f6:ce:17:c6:60:09:5b:49:3d:cb:a0:db:ec: 29:91:85:8b:c3:f5:6c:6a:3c:01:87:12:85:ae:fc: 9e:bf:67:81:1b:1d:b1:9d:12:bd:79:8c:54:08:48: 11:13:6d:ab:b0:16:ef:11:4a:27:a7:0a:80:b3:db: 72:c1:cc:1e:e8:4a:39:b7:00:ca:97:b7:3a:6e:e9: 25:22:2e:5c:57:ee:62:be:23:d0:5e:53:a3:9f:05: d4:7d:7f:b5:b6:cb:4b:27:90:14:79:72:a5:43:97: c6:6a:7d:f7:32:b3:67:58:90:fc:c3:65:34:57:89: 1b:43:28:68:43:24:12:5e:f1:43:76:3c:e9:bc:9c: 5d:7d:ae:d6:3a:31:32:ca:df:a4:07:88:a2:55:6e: a4:8c:da:13:c8:30:b7:2a:1c:23:0f:32:da:9e:7f: e1:f7:3d:2d:1c:58:f5:1d:f2:7d:fb:67:45:8d:dd: 84:eb:83:c4:b0:00:a6:c2:09:b0:48:48:f9:4e:a8: d7:ab:e1:c6:e8:bf:5c:fa:e3:f2:cd:c6:f1:e7:f2: 2c:90 P: 00:e5:4e:f4:32:f8:4a:ec:28:3c:dd:32:a8:05:e3: 5a:fa:a5:81:47:98:d9:a7:94:ba:34:b0:f9:7b:20: c5:fb:52:12:3e:82:d7:6e:6f:f5:50:be:5e:9f:df: 82:9b:4e:0c:9d:a2:9f:3f:0a:f3:72:c2:55:7c:46: 6e:fe:48:00:88:b6:4e:4f:9b:19:8c:98:3b:71:42: 56:d2:b4:1c:47:69:6e:fc:f0:e6:26:04:0e:e2:63: ed:06:0f:fb:a8:a9:94:73:e1:41:e0:6b:5a:b4:d9: 86:cd:7b:46:d3:39:ba:18:13:da:f2:3a:7b:dc:41: 21:83:e8:0d:25:13:31:90:5d:bd:82:41:9b:ea:6b: 8a:ba:8a:48:b1:1d:d2:3d:5e:c4:1b:29:5e:7f:b6: 56:1b:e6:91:65:ec:84:82:c2:f6:a1:b0:14:1b:0b: 08:d8:2b:2a:06:17:d7:2a:9b:c3:aa:fb:28:26:14: 3f:5d:0a:48:1a:48:45:c0:fd:ea:ec:90:6c:ec:93: c8:af:a3:31:4b:3a:d8:cd:20:ae:8f:14:58:26:49: 18:1f:7a:99:c9:da:c3:f0:76:b8:52:8d:eb:b2:e2: 98:6b:a5:47:15:c3:ff:c8:e7:6c:d3:db:c7:fb:4c: 36:3e:15:eb:45:e1:4a:5d:01:ed:3b:87:f7:69:c1: 31:59 Q: 00:ca:6d:df:fc:7b:96:2e:35:30:27:4f:1f:cf:57: 2f:e9:4c:40:97:53:a1:fa:d0:89:56:8d:2c:25 G: 43:26:04:66:b3:80:c3:3f:8d:f5:5a:29:79:58:7a: 0b:8c:72:b9:cb:23:61:5d:c1:45:c5:38:7f:33:4e: 93:63:75:8a:b0:44:61:8f:59:df:fd:2f:3f:1f:22: 73:66:ba:53:65:53:2a:57:5b:d9:40:34:be:4c:78: 22:4a:bf:94:5d:23:15:65:66:e1:1f:6b:93:12:00: f0:ac:f5:64:0d:6d:6c:a3:eb:26:83:6d:68:95:e0: 2c:bf:75:62:fa:5f:95:0f:b0:40:68:ce:66:3b:58: ed:c1:63:e3:d8:35:5c:cc:db:b8:12:e6:62:e4:63: b6:29:e0:86:75:79:bc:95:27:74:d1:fd:94:b9:7f: 6e:57:b4:e5:39:a2:15:41:94:3f:47:90:43:a5:da: dd:08:a4:92:c5:bf:ef:34:4e:2e:7e:82:5c:07:0e: dc:5d:6b:79:10:04:53:cc:b2:8e:bd:65:61:80:49: ad:c7:dd:5f:5a:9b:74:ae:bc:e0:49:f1:ad:4c:1e: 8f:4e:9d:39:e9:fe:57:4d:39:b7:ba:69:03:e3:7e: 4d:0d:9b:65:c3:55:77:ff:2c:86:27:21:c7:3e:60: a3:23:a5:e8:7e:0d:29:15:1c:5e:04:91:91:25:03: f3:97:77:6c:11:24:34:58:c9:ec:b7:ca:ce:74:cd: a7</code></pre> <p>This shows the keys indeed match (JSON <code>x,y</code>, above <code>priv,pub</code>):</p> <pre><code>$ grep --max-count=1 '"x"' remote_timings.json "x": "0x1F8768EB57E1F4F129A6C8CA03C8DB491D8E2B81BD7292640C1CD66D", $ grep --max-count=1 '"y"' remote_timings.json "y": "0x9DFABC4700CB11FA5145C1BDB1882DDDA2795BC3430AAFBB83E2D584D10701ABF9AE762DDDF2A575F53E944D3BC6F6CE17C660095B493DCBA0DBEC2991858BC3F56C6A3C01871285AEFC9EBF67811B1DB19D12BD798C54084811136DABB016EF114A27A70A80B3DB72C1CC1EE84A39B700CA97B73A6EE925222E5C57EE62BE23D05E53A39F05D47D7FB5B6CB4B2790147972A54397C66A7DF732B3675890FCC3653457891B4328684324125EF143763CE9BC9C5D7DAED63A3132CADFA40788A2556EA48CDA13C830B72A1C230F32DA9E7FE1F73D2D1C58F51DF27DFB67458DDD84EB83C4B000A6C209B04848F94EA8D7ABE1C6E8BF5CFAE3F2CDC6F1E7F22C90",</code></pre> <p>This shows the DSA parameters match (JSON <code>p,q,g</code>, above <code>P,Q,G</code>):</p> <pre><code>$ grep --max-count=1 '"p"' remote_timings.json "p": "0xE54EF432F84AEC283CDD32A805E35AFAA5814798D9A794BA34B0F97B20C5FB52123E82D76E6FF550BE5E9FDF829B4E0C9DA29F3F0AF372C2557C466EFE480088B64E4F9B198C983B714256D2B41C47696EFCF0E626040EE263ED060FFBA8A99473E141E06B5AB4D986CD7B46D339BA1813DAF23A7BDC412183E80D251331905DBD82419BEA6B8ABA8A48B11DD23D5EC41B295E7FB6561BE69165EC8482C2F6A1B0141B0B08D82B2A0617D72A9BC3AAFB2826143F5D0A481A4845C0FDEAEC906CEC93C8AFA3314B3AD8CD20AE8F14582649181F7A99C9DAC3F076B8528DEBB2E2986BA54715C3FFC8E76CD3DBC7FB4C363E15EB45E14A5D01ED3B87F769C13159", $ grep --max-count=1 '"q"' remote_timings.json "q": "0xCA6DDFFC7B962E3530274F1FCF572FE94C409753A1FAD089568D2C25", $ grep --max-count=1 '"g"' remote_timings.json "g": "0x43260466B380C33F8DF55A2979587A0B8C72B9CB23615DC145C5387F334E9363758AB044618F59DFFD2F3F1F227366BA5365532A575BD94034BE4C78224ABF945D23156566E11F6B931200F0ACF5640D6D6CA3EB26836D6895E02CBF7562FA5F950FB04068CE663B58EDC163E3D8355CCCDBB812E662E463B629E0867579BC952774D1FD94B97F6E57B4E539A21541943F479043A5DADD08A492C5BFEF344E2E7E825C070EDC5D6B79100453CCB28EBD65618049ADC7DD5F5A9B74AEBCE049F1AD4C1E8F4E9D39E9FE574D39B7BA6903E37E4D0D9B65C35577FF2C862721C73E60A323A5E87E0D29151C5E0491912503F397776C11243458C9ECB7CACE74CDA7",</code></pre> <p>Example: Extract a single entry</p> <p>Here we use the python script <code>pickone.py</code> to extract the entry at index 2 (starting from 0).</p> <pre><code>$ python3 pickone.py remote_timings.json 2 | jq . > 2.json $ cat 2.json { "latency": "399901598", "y": "0x9DFABC4700CB11FA5145C1BDB1882DDDA2795BC3430AAFBB83E2D584D10701ABF9AE762DDDF2A575F53E944D3BC6F6CE17C660095B493DCBA0DBEC2991858BC3F56C6A3C01871285AEFC9EBF67811B1DB19D12BD798C54084811136DABB016EF114A27A70A80B3DB72C1CC1EE84A39B700CA97B73A6EE925222E5C57EE62BE23D05E53A39F05D47D7FB5B6CB4B2790147972A54397C66A7DF732B3675890FCC3653457891B4328684324125EF143763CE9BC9C5D7DAED63A3132CADFA40788A2556EA48CDA13C830B72A1C230F32DA9E7FE1F73D2D1C58F51DF27DFB67458DDD84EB83C4B000A6C209B04848F94EA8D7ABE1C6E8BF5CFAE3F2CDC6F1E7F22C90", "g": "0x43260466B380C33F8DF55A2979587A0B8C72B9CB23615DC145C5387F334E9363758AB044618F59DFFD2F3F1F227366BA5365532A575BD94034BE4C78224ABF945D23156566E11F6B931200F0ACF5640D6D6CA3EB26836D6895E02CBF7562FA5F950FB04068CE663B58EDC163E3D8355CCCDBB812E662E463B629E0867579BC952774D1FD94B97F6E57B4E539A21541943F479043A5DADD08A492C5BFEF344E2E7E825C070EDC5D6B79100453CCB28EBD65618049ADC7DD5F5A9B74AEBCE049F1AD4C1E8F4E9D39E9FE574D39B7BA6903E37E4D0D9B65C35577FF2C862721C73E60A323A5E87E0D29151C5E0491912503F397776C11243458C9ECB7CACE74CDA7", "h": "0xC7DEAC64C95157992CB0D77CF944CB107C756F3E30D1C49C0C48A6EA", "k": "0x742A7562E2A192996440AE2A4FDF5D37E1A532E1E6A50BCA3964BBDA", "q": "0xCA6DDFFC7B962E3530274F1FCF572FE94C409753A1FAD089568D2C25", "p": "0xE54EF432F84AEC283CDD32A805E35AFAA5814798D9A794BA34B0F97B20C5FB52123E82D76E6FF550BE5E9FDF829B4E0C9DA29F3F0AF372C2557C466EFE480088B64E4F9B198C983B714256D2B41C47696EFCF0E626040EE263ED060FFBA8A99473E141E06B5AB4D986CD7B46D339BA1813DAF23A7BDC412183E80D251331905DBD82419BEA6B8ABA8A48B11DD23D5EC41B295E7FB6561BE69165EC8482C2F6A1B0141B0B08D82B2A0617D72A9BC3AAFB2826143F5D0A481A4845C0FDEAEC906CEC93C8AFA3314B3AD8CD20AE8F14582649181F7A99C9DAC3F076B8528DEBB2E2986BA54715C3FFC8E76CD3DBC7FB4C363E15EB45E14A5D01ED3B87F769C13159", "s": "0x79FD73D901BB077D14334D8CC714804577515A1E0ADC9F995BB7534C", "r": "0x61F949D772E22EA9EFBB36442BC229767B28BE2A8061FA7339AFDDC8", "msg": "0x318198301A06092A864886F70D010903310D060B2A864886F70D0109100104301C06092A864886F70D010905310F170D3230303432343131333135375A302B060B2A864886F70D010910020C311C301A30183016041470AD64D33E65A855E6C332AA52736F71D58E7527302F06092A864886F70D0109043122042090C90BFC7A8C459EDB5AF58A8878EE826B6FD02A20E2BAAF2C73984FA380FDD2", "x": "0x1F8768EB57E1F4F129A6C8CA03C8DB491D8E2B81BD7292640C1CD66D", "id": "335451053151725", "k_len": "223" }</code></pre> <p>Example: Dump message to binary file</p> <p>Extract the <code>msg</code> field from the target JSON and dump it as binary.</p> <pre><code>$ sed -n 's/^ "msg": "0x\(.*\)",$/\1/p' 2.json | xxd -r -p > 2.msg $ xxd -g1 2.msg 00000000: 31 81 98 30 1a 06 09 2a 86 48 86 f7 0d 01 09 03 1..0...*.H...... 00000010: 31 0d 06 0b 2a 86 48 86 f7 0d 01 09 10 01 04 30 1...*.H........0 00000020: 1c 06 09 2a 86 48 86 f7 0d 01 09 05 31 0f 17 0d ...*.H......1... 00000030: 32 30 30 34 32 34 31 31 33 31 35 37 5a 30 2b 06 200424113157Z0+. 00000040: 0b 2a 86 48 86 f7 0d 01 09 10 02 0c 31 1c 30 1a .*.H........1.0. 00000050: 30 18 30 16 04 14 70 ad 64 d3 3e 65 a8 55 e6 c3 0.0...p.d.>e.U.. 00000060: 32 aa 52 73 6f 71 d5 8e 75 27 30 2f 06 09 2a 86 2.Rsoq..u'0/..*. 00000070: 48 86 f7 0d 01 09 04 31 22 04 20 90 c9 0b fc 7a H......1". ....z 00000080: 8c 45 9e db 5a f5 8a 88 78 ee 82 6b 6f d0 2a 20 .E..Z...x..ko.* 00000090: e2 ba af 2c 73 98 4f a3 80 fd d2 ...,s.O....</code></pre> <p>Note the <code>xxd</code> output matches the <code>msg</code> byte string from the target JSON.</p> <p>Example: Dump hash to binary file</p> <p>Extract the <code>h</code> field from the target JSON and dump it as binary.</p> <pre><code>$ sed -n 's/^ "h": "0x\(.*\)",$/\1/p' 2.json | xxd -r -p > 2.hash $ xxd -g1 2.hash 00000000: c7 de ac 64 c9 51 57 99 2c b0 d7 7c f9 44 cb 10 ...d.QW.,..|.D.. 00000010: 7c 75 6f 3e 30 d1 c4 9c 0c 48 a6 ea |uo>0....H..</code></pre> <p>Note the <code>xxd</code> output matches the <code>h</code> byte string from the target JSON.</p> <p>Example: Hash is consistent</p> <pre><code>$ sha256sum 2.msg c7deac64c95157992cb0d77cf944cb107c756f3e30d1c49c0c48a6ea809e6d58 2.msg</code></pre> <p>Note the first 28 bytes of <code>sha256sum</code> output match the <code>h</code> byte string from the target JSON. (DSA maps to GF(q) with truncation.)</p> <p>Example: Dump signature to DER</p> <p>The <code>hex2der.sh</code> script takes as an argument the target JSON filename, and outputs the DER-encoded DSA signature to stdout by extracting the <code>r</code> and <code>s</code> fields from the target JSON.</p> <pre><code>$ ./hex2der.sh 2.json > 2.der $ openssl asn1parse -in 2.der -inform DER 0:d=0 hl=2 l= 60 cons: SEQUENCE 2:d=1 hl=2 l= 28 prim: INTEGER :61F949D772E22EA9EFBB36442BC229767B28BE2A8061FA7339AFDDC8 32:d=1 hl=2 l= 28 prim: INTEGER :79FD73D901BB077D14334D8CC714804577515A1E0ADC9F995BB7534C</code></pre> <p>Note the <code>asn1parse</code> output contains a sequence with two integers, matching the <code>r</code> and <code>s</code> fields from the target JSON.</p> <p>Example: Verify the signature (post-hash)</p> <p>We use <code>pkeyutl</code> here to verify the raw hash directly.</p> <pre><code>$ openssl pkeyutl -in 2.hash -inkey public.pem -pubin -verify -sigfile 2.der Signature Verified Successfully</code></pre> <p>Note it fails for other hashes (messages), a fundamental security property for digital signatures:</p> <pre><code>$ dd if=/dev/urandom of=bad.hash bs=1 count=28 28+0 records in 28+0 records out 28 bytes copied, 0.000647097 s, 43.3 kB/s $ openssl pkeyutl -in bad.hash -inkey public.pem -pubin -verify -sigfile 2.der Signature Verification Failure</code></pre> <p>Example: Verify the signature (pre-hash)</p> <p>We use <code>dgst</code> here to verify by recomputing the hash.</p> <pre><code>$ openssl dgst -sha256 -verify public.pem -signature 2.der 2.msg Verified OK</code></pre> <p>Example: Message analysis</p> <p>The <code>msg</code> JSON field is an <a href="https://tools.ietf.org/html/rfc3161">RFC 3161</a> Time Stamp Request. You can examine it:</p> <pre><code>$ openssl asn1parse -in 2.msg -inform DER 0:d=0 hl=3 l= 152 cons: SET 3:d=1 hl=2 l= 26 cons: SEQUENCE 5:d=2 hl=2 l= 9 prim: OBJECT :contentType 16:d=2 hl=2 l= 13 cons: SET 18:d=3 hl=2 l= 11 prim: OBJECT :id-smime-ct-TSTInfo 31:d=1 hl=2 l= 28 cons: SEQUENCE 33:d=2 hl=2 l= 9 prim: OBJECT :signingTime 44:d=2 hl=2 l= 15 cons: SET 46:d=3 hl=2 l= 13 prim: UTCTIME :200424113157Z 61:d=1 hl=2 l= 43 cons: SEQUENCE 63:d=2 hl=2 l= 11 prim: OBJECT :id-smime-aa-signingCertificate 76:d=2 hl=2 l= 28 cons: SET 78:d=3 hl=2 l= 26 cons: SEQUENCE 80:d=4 hl=2 l= 24 cons: SEQUENCE 82:d=5 hl=2 l= 22 cons: SEQUENCE 84:d=6 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:70AD64D33E65A855E6C332AA52736F71D58E7527 106:d=1 hl=2 l= 47 cons: SEQUENCE 108:d=2 hl=2 l= 9 prim: OBJECT :messageDigest 119:d=2 hl=2 l= 34 cons: SET 121:d=3 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:90C90BFC7A8C459EDB5AF58A8878EE826B6FD02A20E2BAAF2C73984FA380FDD2</code></pre> <p>Example: Statistics</p> <p>The <code>stats.py</code> script shows how to extract the desired fields from the JSON. It computes the median latency over each nonce bit length.</p> <pre><code>$ python3 stats.py remote_timings.json Len Median 205 121.2 206 121.2 207 120.6 208 138.3 209 122.9 210 123.0 211 123.0 212 123.0 213 125.0 214 125.0 215 125.0 216 125.0 217 127.1 218 127.1 219 127.1 220 127.1 221 129.1 222 129.1 223 129.1 224 129.1</code></pre> <p>You can verify these medians are consistent with Figure 1 in the paper.</p> <p>The <code>stats.py</code> script can be easily modified for more advanced analysis.</p> <p>Credits</p> <p>Some parts borrowed from <a href="https://doi.org/10.5281/zenodo.3736311">this artifact</a>.</p> <p>Authors</p> <ul> <li>Sohaib ul Hassan (Tampere University, Tampere, Finland)</li> <li>Iaroslav Gridin (Tampere University, Tampere, Finland)</li> <li>Ignacio M. Delgado-Lozano (Tampere University, Tampere, Finland)</li> <li>Cesar Pereida García (Tampere University, Tampere, Finland)</li> <li>Jesús-Javier Chi-Domínguez (Tampere University, Tampere, Finland)</li> <li>Alejandro Cabrera Aldaya (Tampere University, Tampere, Finland)</li> <li>Billy Bob Brumley (Tampere University, Tampere, Finland)</li> </ul> <p>Funding</p> <p>This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 804476).</p> <p>License</p> <p>This project is distributed under <a href="LICENSE">MIT license</a>.</p>
Figure 9. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 9. - Information flows between EU BON and LTER Europe, as envisaged on the 3rd EU BON Stakeholder Roundtable in Granada on 9-11 December 2015.
Figure 8. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 8. - The patchiness of survey coverage in Europe illustrated by the distribution map of Plantago lanceolata taken from GBIF in 2016. This species is one of the commonest and most widespread in Europe, it should occur in almost all areas of this map, but in fact the data traces out the borders of countries and area who have published data on GBIF.
Figure 6. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 6. - Individual Metacat instances can be connected to DataOne which replicates public files. Thus the data is still available if a single instance goes offline.https://search.dataone.org/#data/page/0
Figure 5. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 5. - PPBio has installed a Metacat instance for their researchers to upload and make publicly available the results of work related to biodiversity in the Western Amazon.https://ppbiodata.inpa.gov.br/metacatui/
Figure 4. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 4. - The public data repository provided by the Knowledge Network for Biocomplexity (KNB).https://knb.ecoinformatics.org/#data/page/0
Figure 3. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 3. - The implementation of Darwin Core Archive in Plazi to transfer treatment data. Observation data described with Darwin Core terms.
Figure 1. from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
Figure 1. - ARPHA consists of two integrated workflows: in ARPHA-XML, the manuscript is written and processed via the ARPHA Writing Tool, and in ARPHA-DOC, the manuscript is submitted and processed as document file(s).
Research compendium for 'The contribution of integrated 3D model analysis to Protoaurignacian stone tool design'
<p><strong>Abstract:</strong> Protoaurignacian foragers relied heavily on the production and use of bladelets. Techno-typological studies of these implements have provided insights into important aspects of cultural variability. However, new technologies have seldom been used to quantify patterns of stone tool design. Taking advantage of a new scanning protocol and open-source software, we conduct the first 3D analysis of a Protoaurignacian assemblage, focusing on the selection and modification of blades and bladelets. We study a large sample of complete blanks and retouched tools from the early Protoaurignacian assemblage at Fumane Cave in northeastern Italy. Our main goal is to validate and refine previous techno-typological considerations employing a 3D geometric morphometrics approach complemented by 2D analysis of cross-section outlines and computations of retouch angle. The encouraging results show the merits of the proposed integrated approach and confirm that bladelets were the main focus of stone knapping at the site. Among modified bladelets, various retouching techniques were applied to achieve specific shape objectives. We suggest that the variability observed among retouched bladelets relates to the design of multi-part artifacts that need to be further explored via renewed experimental and functional studies.</p> <p><strong>Overview of contents:</strong></p> <p>01. AGMT3-D project of the first dataset used in the study;</p> <p>02. AGMT3-D project of the second dataset used in the study;</p> <p>03. Raw outline data of the middle cross-section. Each specimens has a dedicate .txt file;</p> <p>04. Raw outline data of the upper cross-section. Each specimens has a dedicate .txt file;</p> <p>05. Angles3-D project with all files generated by the software (.mat and .xlsx formats) to quantify the mean retouch angle of retouched bladelets;</p> <p>06. R project and scripts for the 1) 2D shape analysis of the middle and upper cross-sections of retouched bladelets and the 2) design of all bivariate plots and boxplots with jittered points used in the paper. All related datasets, principal components, and generated figures are included in the folder;</p> <p>07. Folder with all figures published in the paper and in its supplementary materials;</p> <p>08. Dataset of the first study in .csv with all attributes used to run the statistical analysis presented in the paper;</p> <p>09. Dataset of the second study in .csv with all attributes used to run the statistical analysis presented in the paper;</p> <p>10. Dataset for the study of the upper cross-sections in .csv with all attributes used to run the statistical analysis presented in the paper;</p> <p>11. Dataset for the study of the middle cross-sections in .csv with all attributes used to run the statistical analysis presented in the paper;</p> <p>12. Dataset in .csv used to study the mean retouch angles;</p> <p>13. Supplementary information file in .pdf with all supplementary figures and tables.</p> <p><strong>Extra</strong>: All 3D meshes of blades and bladelets are available on Zenodo following this link: https://doi.org/10.5281/zenodo.6362150.</p>
F-UJI and FAIR Enough tool comparison dataset (European Research Data Landscape study)
<p>Dataset used to compare the assessment results on the levels of Findability, Accessability, Interoperability and Reusability of datasets in a sample of repositories, by means of the F-UJI FAIR data assessment tool and FAIR-Enough assessment tool. Assessment carried out for the European Research Data Landscape study.</p>
Data and tools of the landscape and cost analysis of data repositories currently used by the Swiss research community
<p>This file collection is part of the ORD Landscape and Cost Analysis Project (DOI: 10.5281/zenodo.2643460), a study jointly commissioned by the SNSF and swissuniversities in 2018.</p> <p>Please cite this data collection as:<br> von der Heyde, M. (2019). Data and tools of the landscape and cost analysis of data repositories currently used by the Swiss research community. Retrieved from https://doi.org/10.5281/zenodo.2643495</p> <p>Connected data papers are:<br> von der Heyde, M. (2019). Open Data Landscape: Repository Usage of the Swiss Research Community: Description of collection, collected data, and analysis methods [Data paper]. Retrieved from https://doi.org/10.5281/zenodo.2643430<br> von der Heyde, M. (2019). International Open Data Repository Survey: Description of collection, collected data, and analysis methods [Data paper]. Retrieved from https://doi.org/10.5281/zenodo.2643450</p> <p>Connected data sets are:<br> von der Heyde, M. (2019). Data from the Swiss Open Data Repository Landscape survey. Retrieved from https://doi.org/10.5281/zenodo.2643487<br> von der Heyde, M. (2019). Data from the International Open Data Repository Survey. Retrieved from https://doi.org/10.5281/zenodo.2643493</p> <p> </p> <p><strong>Contact</strong></p> <p>Swiss National Science Foundation (SNSF)</p> <p>Open Research Data Group</p> <p>E-mail: <a href="mailto:ord@snf.ch">ord@snf.ch</a></p> <p> </p> <p>swissuniversities</p> <p>Program "Scientific Information"</p> <p>Gabi Schneider</p> <p>E-Mail: <a href="mailto:isci@swissuniversities.ch">isci@swissuniversities.ch</a></p>
Chemical variations in Quercus pollen as a tool for taxonomic identification: implications for long-term ecological and biogeographical research
<p><strong>Aim</strong> </p> <p>Fossil pollen is an important tool for understanding biogeographic patterns in the past, but the taxonomic resolution of the fossil-pollen record may be limited to genus or even family level. Chemical analysis of pollen grains has the potential to increase the taxonomic resolution of pollen, but present-day chemical variability is poorly understood. This study aims to investigate whether a phylogenetic signal is present in the chemical variations of <em>Quercus</em> L. pollen and to assess the prospects of chemical techniques for identification in biogeographic research.</p> <p><strong>Location</strong> </p> <p>Portugal</p> <p><strong>Taxon</strong> </p> <p>Six taxa (five species, one subspecies) of <em>Quercus</em> L., <em>Q. faginea, Q. robur, Q. robur</em> ssp. <em>estremadurensis, Q. coccifera, Q. rotundifolia</em> and <em>Q. suber</em> belonging to three sections: <em>Cerris, Ilex</em>, and <em>Quercus</em> (<a href="https://www.biorxiv.org/content/10.1101/761148v2#ref-13">Denk, Grimm, Manos, Deng, & Hipp, 2017</a>)</p> <p><strong>Methods</strong> </p> <p>We collected pollen samples from 297 individual <em>Quercus</em> trees across a 4° (∼450 km) latitudinal gradient and determined chemical differences using Fourier-transform infrared spectroscopy (FTIR). We used canonical powered partial least-squares regression (CPPLS) and discriminant analysis to describe within- and between-species chemical variability.</p> <p><strong>Results</strong> </p> <p>We find clear differences in the FTIR spectra from <em>Quercus</em> pollen at the section level (<em>Cerris</em>: ∼98%; <em>Ilex</em>: ∼100%; <em>Quercus</em>: ∼97%). Successful discrimination is based on spectral signals related to lipids and sporopollenins. However, discrimination of species within individual <em>Quercus</em> sections is more difficult: overall, species recall is ∼76% and species misidentifications within sections lie between 18% and 31% of the test-set.</p> <p><strong>Main Conclusions</strong> </p> <p>Our results demonstrate that subgenus level differentiation of <em>Quercus</em> pollen is possible using FTIR methods, with successful classification at the section level. This indicates that operator-independent FTIR approaches can surpass traditional morphological techniques using the light microscope. Our results have implications both for providing new insights into past colonisation pathways of <em>Quercus</em>, and likewise for forecasting future responses to climate change. However, before FTIR techniques can be applied more broadly across palaeoecology and biogeography, our results also highlight a number of research challenges that still need to be addressed, including developing sporopollenin-specific taxonomic discriminators and determining a more complete understanding of the effects of environmental variation on pollen-chemical signatures in <em>Quercus</em>.</p>
Supplementary material 3: List of tested and analyzed data sharing tools (non-exhaustive) from: Data sharing tools adopted by the European Biodiversity Observation Network Project - Research Ideas and Outcomes 2: e9390 (31 May 2016) https://doi.org/10.3897/rio.2.e9390
List of tested and analyzed data sharing tools (non-exhaustive)
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.