Dash RELIC: A Modern Cryptographic Meta-toolkit

RELIC is a modern cryptographic meta-toolkit with emphasis on efficiency and flexibility. RELIC can be used to build efficient and usable cryptographic toolkits tailored for specific security levels and algorithmic choices.

Goals

RELIC is an ongoing project and features will be added on demand. The focus is to provide:

• Ease of portability and inclusion of architecture-dependent code
• Simple experimentation with alternative implementations
• Tests and benchmarks for every implemented function
• Flexible configuration
• Maximum efficiency

Algorithms

RELIC implements to date:

• Multiple-precision integer arithmetic
• Prime and Binary field arithmetic
• Elliptic curves over prime and binary fields (NIST curves and pairing-friendly curves)
• Bilinear maps and related extension fields
• Cryptographic protocols (RSA, Rabin, ECDSA, ECMQV, ECSS (Schnorr), ECIES, Sakai-Ohgishi-Kasahara ID-based authenticated key agreement, Boneh-Lynn-Schacham and Boneh-Boyen short signatures, Paillier and Benaloh homomorphic encryption systems)

Citing

If you use RELIC, please cite using the template below:

@misc{relic-toolkit,
    author = {D. F. Aranha and C. P. L. Gouvêa and T. Markmann and R. S. Wahby and K. Liao},        
    title = {{RELIC is an Efficient LIbrary for Cryptography}},
    howpublished = {\url{https://github.com/relic-toolkit/relic}},
}

Build instructions

Instructions for building the library can be found in the Wiki.

Support

You can probably get some help over the official mailing list at relic-discuss@googlegroups.com

If you like the library, please consider supporting development through Paypal.

Disclaimer

RELIC is at most alpha-quality software. Implementations may not be correct or secure and may include patented algorithms. There are many configuration options which make the library horribly insecure. Backward API compatibility with early versions may not necessarily be maintained. Use at your own risk.

Download Details:
Author: dashpay
Source Code: https://github.com/dashpay/relic
License: View license

#dash  #blockchain  #crypto #c 

What is GEEK

Buddha Community

Dash RELIC: A Modern Cryptographic Meta-toolkit

RELIC is a modern cryptographic meta-toolkit with emphasis on efficiency and flexibility. RELIC can be used to build efficient and usable cryptographic toolkits tailored for specific security levels and algorithmic choices.

Goals

RELIC is an ongoing project and features will be added on demand. The focus is to provide:

• Ease of portability and inclusion of architecture-dependent code
• Simple experimentation with alternative implementations
• Tests and benchmarks for every implemented function
• Flexible configuration
• Maximum efficiency

Algorithms

RELIC implements to date:

• Multiple-precision integer arithmetic
• Prime and Binary field arithmetic
• Elliptic curves over prime and binary fields (NIST curves and pairing-friendly curves)
• Bilinear maps and related extension fields
• Cryptographic protocols (RSA, Rabin, ECDSA, ECMQV, ECSS (Schnorr), ECIES, Sakai-Ohgishi-Kasahara ID-based authenticated key agreement, Boneh-Lynn-Schacham and Boneh-Boyen short signatures, Paillier and Benaloh homomorphic encryption systems)

Citing

If you use RELIC, please cite using the template below:

@misc{relic-toolkit,
    author = {D. F. Aranha and C. P. L. Gouvêa and T. Markmann and R. S. Wahby and K. Liao},        
    title = {{RELIC is an Efficient LIbrary for Cryptography}},
    howpublished = {\url{https://github.com/relic-toolkit/relic}},
}

Build instructions

Instructions for building the library can be found in the Wiki.

Support

You can probably get some help over the official mailing list at relic-discuss@googlegroups.com

If you like the library, please consider supporting development through Paypal.

Disclaimer

RELIC is at most alpha-quality software. Implementations may not be correct or secure and may include patented algorithms. There are many configuration options which make the library horribly insecure. Backward API compatibility with early versions may not necessarily be maintained. Use at your own risk.

Download Details:
Author: dashpay
Source Code: https://github.com/dashpay/relic
License: View license

#dash  #blockchain  #crypto #c 

Workshop Alert! Hands-on Meta-Learning

The Association of Data Scientists (AdaSci), the premier global professional body of data science and ML practitioners, has announced a hands-on workshop on meta-learning on March 13, Saturday.

The unavailability of large datasets has turned out to be a huge problem in solving critical challenges with machine learning and artificial intelligence. As a matter of fact, deep learning’s progress often gets impeded due to the unavailability of adequate labelled data.

In many cases, it becomes challenging to collect a sufficiently large number of labelled data, which inspired many research efforts on exploring ways to train robust models for various learning tasks beyond labelled data. Further, to train complex deep learning algorithms and models need high computational power.

In this workshop, the attendees get to learn about meta-learning — a subfield of machine learning where deep learning models are trained with fewer data efficiently. Known as ‘learning how to learn,’ meta-learning is an exciting trend in machine learning.

#featured #meta-learning applications #meta-learning workshop #meta-learning-algorithms #workshop on meta-learning

BLS Signatures in C++ using The Relic toolkit In Dash

BLS Signatures implementation

NOTE: THIS LIBRARY IS A DRAFT AND NOT YET REVIEWED FOR SECURITY

Implements BLS signatures with aggregation as in Boneh, Drijvers, Neven 2018, using relic toolkit for cryptographic primitives (pairings, EC, hashing). The BLS12-381 curve is used. The spec is here.

Features:

• Non-interactive signature aggregation on identical or distinct messages
• Aggregate aggregates (trees)
• Efficient verification (only one pairing per distinct message)
• Security against rogue public key attack
• Aggregate public keys and private keys
• HD (BIP32) key derivation
• Key and signature serialization
• Batch verification
• Signature division (divide an aggregate by a previously verified signature)
• Python bindings
• Pure python bls12-381 and signatures

Import the library

#include "bls.hpp"

Creating keys and signatures

// Example seed, used to generate private key. Always use
// a secure RNG with sufficient entropy to generate a seed.
uint8_t seed[] = {0, 50, 6, 244, 24, 199, 1, 25, 52, 88, 192,
                  19, 18, 12, 89, 6, 220, 18, 102, 58, 209,
                  82, 12, 62, 89, 110, 182, 9, 44, 20, 254, 22};

bls::PrivateKey sk = bls::PrivateKey::FromSeed(seed, sizeof(seed));
bls::PublicKey pk = sk.GetPublicKey();

uint8_t msg[] = {100, 2, 254, 88, 90, 45, 23};

bls::Signature sig = sk.Sign(msg, sizeof(msg));

Serializing keys and signatures to bytes

uint8_t skBytes[bls::PrivateKey::PRIVATE_KEY_SIZE];  // 32 byte array
uint8_t pkBytes[bls::PublicKey::PUBLIC_KEY_SIZE];    // 48 byte array
uint8_t sigBytes[bls::Signature::SIGNATURE_SIZE];    // 96 byte array

sk.Serialize(skBytes);   // 32 bytes
pk.Serialize(pkBytes);   // 48 bytes
sig.Serialize(sigBytes); // 96 bytes

Loading keys and signatures from bytes

// Takes array of 32 bytes
sk = bls::PrivateKey::FromBytes(skBytes);

// Takes array of 48 bytes
pk = bls::PublicKey::FromBytes(pkBytes);

// Takes array of 96 bytes
sig = bls::Signature::FromBytes(sigBytes);

Verifying signatures

// Add information required for verification, to sig object
sig.SetAggregationInfo(bls::AggregationInfo::FromMsg(pk, msg, sizeof(msg)));

bool ok = sig.Verify();

Aggregate signatures for a single message

// Generate some more private keys
seed[0] = 1;
bls::PrivateKey sk1 = bls::PrivateKey::FromSeed(seed, sizeof(seed));
seed[0] = 2;
bls::PrivateKey sk2 = bls::PrivateKey::FromSeed(seed, sizeof(seed));

// Generate first sig
bls::PublicKey pk1 = sk1.GetPublicKey();
bls::Signature sig1 = sk1.Sign(msg, sizeof(msg));

// Generate second sig
bls::PublicKey pk2 = sk2.GetPublicKey();
bls::Signature sig2 = sk2.Sign(msg, sizeof(msg));

// Aggregate signatures together
vector<bls::Signature> sigs = {sig1, sig2};
bls::Signature aggSig = bls::Signature::Aggregate(sigs);

// For same message, public keys can be aggregated into one.
// The signature can be verified the same as a single signature,
// using this public key.
vector<bls::PublicKey> pubKeys = {pk1, pk2};
bls::PublicKey aggPubKey = bls::Signature::Aggregate(pubKeys);

Aggregate signatures for different messages

// Generate one more key and message
seed[0] = 3;
bls::PrivateKey sk3 = bls::PrivateKey::FromSeed(seed, sizeof(seed));
bls::PublicKey pk3 = sk3.GetPublicKey();
uint8_t msg2[] = {100, 2, 254, 88, 90, 45, 23};

// Generate the signatures, assuming we have 3 private keys
sig1 = sk1.Sign(msg, sizeof(msg));
sig2 = sk2.Sign(msg, sizeof(msg));
bls::Signature sig3 = sk3.Sign(msg2, sizeof(msg2));

// They can be noninteractively combined by anyone
// Aggregation below can also be done by the verifier, to
// make batch verification more efficient
vector<bls::Signature> sigsL = {sig1, sig2};
bls::Signature aggSigL = bls::Signature::Aggregate(sigsL);

// Arbitrary trees of aggregates
vector<bls::Signature> sigsFinal = {aggSigL, sig3};
bls::Signature aggSigFinal = bls::Signature::Aggregate(sigsFinal);

// Serialize the final signature
aggSigFinal.Serialize(sigBytes);

Verify aggregate signature for different messages

// Deserialize aggregate signature
aggSigFinal = bls::Signature::FromBytes(sigBytes);

// Create aggregation information (or deserialize it)
bls::AggregationInfo a1 = bls::AggregationInfo::FromMsg(pk1, msg, sizeof(msg));
bls::AggregationInfo a2 = bls::AggregationInfo::FromMsg(pk2, msg, sizeof(msg));
bls::AggregationInfo a3 = bls::AggregationInfo::FromMsg(pk3, msg2, sizeof(msg2));
vector<bls::AggregationInfo> infos = {a1, a2};
bls::AggregationInfo a1a2 = bls::AggregationInfo::MergeInfos(infos);
vector<bls::AggregationInfo> infos2 = {a1a2, a3};
bls::AggregationInfo aFinal = bls::AggregationInfo::MergeInfos(infos2);

// Verify final signature using the aggregation info
aggSigFinal.SetAggregationInfo(aFinal);
ok = aggSigFinal.Verify();

// If you previously verified a signature, you can also divide
// the aggregate signature by the signature you already verified.
ok = aggSigL.Verify();
vector<bls::Signature> cache = {aggSigL};
aggSigFinal = aggSigFinal.DivideBy(cache);

// Final verification is now more efficient
ok = aggSigFinal.Verify();

Aggregate private keys

vector<bls::PrivateKey> privateKeysList = {sk1, sk2};
vector<bls::PublicKey> pubKeysList = {pk1, pk2};

// Create an aggregate private key, that can generate
// aggregate signatures
const bls::PrivateKey aggSk = bls::PrivateKey::Aggregate(
        privateKeys, pubKeys);

bls::Signature aggSig3 = aggSk.Sign(msg, sizeof(msg));

HD keys

// Random seed, used to generate master extended private key
uint8_t seed[] = {1, 50, 6, 244, 24, 199, 1, 25, 52, 88, 192,
                  19, 18, 12, 89, 6, 220, 18, 102, 58, 209,
                  82, 12, 62, 89, 110, 182, 9, 44, 20, 254, 22};

bls::ExtendedPrivateKey esk = bls::ExtendedPrivateKey::FromSeed(
        seed, sizeof(seed));

bls::ExtendedPublicKey epk = esk.GetExtendedPublicKey();

// Use i >= 2^31 for hardened keys
bls::ExtendedPrivateKey skChild = esk.PrivateChild(0)
                                .PrivateChild(5);

bls::ExtendedPublicKey pkChild = epk.PublicChild(0)
                               .PublicChild(5);

// Serialize extended keys
uint8_t buffer1[bls::ExtendedPublicKey::ExtendedPublicKeySize]   // 93 bytes
uint8_t buffer2[bls::ExtendedPrivateKey::ExtendedPrivateKeySize] // 77 bytes

pkChild.Serialize(buffer1);
skChild.Serialize(buffer2);

Build

Cmake, a c++ compiler, and python3 (for bindings) are required for building.

git submodule update --init --recursive
mkdir build
cd build
cmake ../
cmake --build . -- -j 6

Run tests

./build/src/runtest

Run benchmarks

./build/src/runbench

Link the library to use it

g++ -Wl,-no_pie  -Ibls-signatures/contrib/relic/include -Ibls-signatures/build/contrib/relic/incl
ude -Ibls-signatures/src/  -L./bls-signatures/build/ -l bls  yourfile.cpp

Notes on dependencies

Changes performed to relic: Added config files for Chia, and added gmp include in relic.h, new ep_map and ep2_map, new ep_pck and ep2_pck. Custom inversion function. Note: relic is used with the Apache 2.0 license.

Libsodium and GMP are optional dependencies: libsodium gives secure memory allocation, and GMP speeds up the library by ~ 3x. To install them, either download them from github and follow the instructions for each repo, or use a package manager like APT or brew.

Discussion

Discussion about this library and other Chia related development is on Keybase. Install Keybase, and run the following to join the Chia public channels:

keybase team request-access chia_network.public

Code style

• Always use uint8_t for bytes
• Use size_t for size variables
• Uppercase method names
• Prefer static constructors
• Avoid using templates
• Objects allocate and free their own memory
• Use cpplint with default rules

TODO

• Serialize aggregation info
• Secure allocation during signing, key derivation
• Threshold signatures
• Remove unnecessary dependency files
• Constant time and side channel attacks
• Adaptor signatures / Blind signatures
• More tests vectors (failed verifications, etc)

Specification and test vectors

The specification and test vectors can be found here. Test vectors can also be seen in the python or cpp test files.

Download Details:
Author: dashpay
Source Code: https://github.com/dashpay/bls-signatures
License: Apache-2.0 License

#dash  #blockchain  #crypto #cpluplus 

Deep Dive Into WordPress Toolkit 4.7 Release

WordPress Tookit 4.7 is the third major WordPress Toolkit update in 2020. It’s also the first update developed and released by a team working completely remotely due to the current lock down. We’re happy to announce that we were still able to deliver as planned. Read on to learn what was added in this release.

What’s WordPress Toolkit?

Update of Paid Plugins & Themes

Most WordPress agencies and web developers are using paid plugins and themes in their projects. Same goes for WordPress admins who’re at least semi-serious about their site. The main problem with such plugins and themes was that they’re not hosted on wordpress.org. Thus, WordPress Toolkit couldn’t detect their updates and install them. This deficiency led to a miserable user experience where you could update a bunch of plugins and themes via WordPress Toolkit. But for the rest, you had to go through WordPress itself. The Smart Updates feature also couldn’t update such plugins and themes, hence limiting its usefulness.

I’m not exaggerating when I say that this was the main known showstopper on the critical user path in WordPress Toolkit. This is why I’m very happy to announce that we have removed this showstopper in WordPress Toolkit 4.7. If you can see and install the plugin or theme update in WordPress itself, you can do the same in WordPress Toolkit now. Let’s take a closer look.

Here’s how these updates are displayed in WordPress itself:

WordPress Toolkit displays these updates in the same way it displays updates for plugins and themes from wordpress.org:

#wordpress toolkit #wordpress toolkit 4.7 #wordpress toolkit 4.7 update #wordpress

Announcing Plesk WordPress Toolkit 4.8 Release

Plesk WordPress Toolkit 4.8 is the fourth major WordPress Toolkit update in 2020. In this release, we focused on several customer-requested features. Including Smart Updates CLI, new notifications for outdated plugins, choosing the default WordPress installation language, and more. Read on to learn what’s new in this release.

Choosing the Default WordPress Installation Language

When users install WordPress via WordPress Toolkit, there’s some magic happening behind the scenes. In particular, we are selecting default WordPress language based on the language of the user who is getting this WordPress installation. So, for example, if my Plesk is switched to Italian when I install WordPress, it will offer Italian as the default WordPress language. If the server admin is using Plesk in English and installs WordPress for a user whose Plesk is in German, the default WordPress language selected on the installation form will be German.

Apparently, either this logic doesn’t work all the time (although we weren’t able to conclusively confirm this). Or some people simply want to use a very specific language by default in all cases. The request from several customers was heard loud and clear. So we delivered this functionality in WordPress Toolkit 4.8. Now server administrators can open global WordPress Toolkit settings and choose a language that should be selected for all WordPress installations on the server by default. Users installing WordPress can choose a different language if they want, obviously.

Let’s take a closer look:

To return the old behavior which selected the language automatically, simply choose the “Same as user language” option (it’s right on top of the list of languages). Oh, and if you’re wondering what’s “Deutch (Österreich)” on the screenshot above, and why you can’t find this language in Plesk, here’s the answer: we’re taking the list of languages from WordPress itself. And it’s bigger than the list of languages supported by Plesk.

Adding CLI for Smart Updates

We’re slowly but surely adding CLI for existing features. And this time it’s Smart Updates feature that gets some love. WordPress Toolkit 4.8 adds the first part of Smart Updates CLI, allowing hosters to enable and disable Smart Updates on a particular site. The second part of Smart Updates CLI will come later. And it will include the ability to fetch Smart Update procedure status and confirm or reject the update.

#plesk news and announcements #product and technology #new releases #plesk wordpress toolkit #smart updates #update #uservoice #wordpress #wordpress toolkit 4.8 #wordpress toolkit for cpanel