Является ли jBCrypt 0.3 многопоточным?

Question

Вопрос говорит обо всем на самом деле. Код можно найти по следующей ссылке -> http://www.mindrot.org/projects/jBCrypt/

Answer 1

Я категорически не согласен с существующими ответами и принятым в настоящее время ответом.

После краткого обзора исходного кода для jBcrypt я удовлетворен тем, что он поточно-ориентирован.Единственный созданный экземпляр не выходит за рамки статического метода ключа hashpw, и его поля не передаются другим экземплярам через какой-либо механизм, который я вижу.

Далее, я действительно смущен жалобами на API, состоящий из статических методов.Хеш-функции чисты, и поэтому нет никаких оснований для , а не предоставлять их статическими методами.Я на самом деле очень рад, что нет доступного пользовательского доступа к методам экземпляров, чтобы какой-то дурак не попытался сделать что-то умное (например, использовать один экземпляр снова и снова, «сбрасывать» его, чтобы минимизировать распределение / сборщик мусора или что-то подобное).1010 *

Answer 2

Воскрешает эту старую проблему, потому что я считаю, что текущие ответы неверны, и эта тема всплывает в поисках Google.

Посмотрел код и провел пару простых тестов.Кажется, что jbcryt является потокобезопасным.

В коде: - хотя он имеет в основном статический метод, эти методы создают экземпляры класса bcrypt для выполнения вычислений при необходимости.

Тестовые образцы: -hadbcrypt не был потокобезопасным, я ожидал, что любой из этих методов выдаст какую-то форму ошибки, которой они не сделали.

@Test
public void multiThreadHash() throws InterruptedException{
    List<Thread> threads = new ArrayList<Thread>();

    for(int i = 0; i<40; i++){
        threads.add(new Thread(){
            @Override
            public void run() {
                long start = System.currentTimeMillis();
                while(System.currentTimeMillis()<start+12000){
                    String password = "sample";
                    String hash = BCrypt.gensalt(4);
                    String hashed = BCrypt.hashpw(password, hash);
                }
            }

        });
    }

    for(Thread t: threads){
        t.start();
    }

    Thread.sleep(12200L);
}

@Test
public void multiThreadReproductibleHash() throws InterruptedException{

    List<Thread> threads = new ArrayList<Thread>();

    for(int i = 0; i<40; i++){
        threads.add(new Thread(){
            @Override
            public void run() {
                long start = System.currentTimeMillis();
                while(System.currentTimeMillis()<start+12000){
                    String password = "sample";
                    String hash = "$2a$04$/YkrS2ifyAloNVUk5qAO7O";
                    String expected = "$2a$04$/YkrS2ifyAloNVUk5qAO7OlqIsp2ECTMDinOij9wvn7nXPRJCo8Gy";
                    String hashed = BCrypt.hashpw(password, hash);
                    Assert.assertEquals(expected, hashed);
                }
            }

        });
    }

    for(Thread t: threads){
        t.start();
    }

    Thread.sleep(12200L);
}

Answer 3

Во-первых, он не задокументирован как поточно-ориентированный, поэтому, по сути, это не так.И, что касается дальнейшего исследования, это определенно не так: оказывается, что, хотя есть некоторые поля экземпляров, нет ни одного экземпляра BCrypt;он пытается сделать все через статические методы.Это не может быть потокобезопасным.Он настолько мал, что, если вы заботитесь и автор согласится, вы можете предложить патч для его тривиального преобразования с целью предоставления отдельных, безопасных экземпляров (отредактировать, чтобы добавить: я тщательно его очистил и подготовил более чистую версию, которую я отправлю наавтор ...)

Во-вторых, каким образом вы хотите использовать это в многопоточной среде?Мне не ясно, что вы хотели бы сделать в отдельных темах.

ПРИМЕЧАНИЕ: Ниже приведено особое мнение с большим количеством голосов против по состоянию на 18.07.2013