Выпущена StringZilla v4 — первая версия библиотеки для обработки строк с поддержкой CUDA, которая ускоряет вычисления на GPU. Она обеспечивает до 500 гигаопераций в секунду для расчёта расстояний Левенштейна и других метрик схожести строк, что в 109 раз быстрее решений на NVIDIA H100. Библиотека оптимизирована для больших объёмов данных в базах данных, биоинформатике и информационном поиске, включая алгоритмы с аффинными штрафами за разрывы и мини-хэширование.

Новые функции включают хэш-функции на основе AES, генераторы псевдослучайных строк и алгоритмы сортировки для работы с коллекциями строк. StringZilla использует SIMD-инструкции на CPU и GPU, поддерживает несколько архитектур и языков программирования. Библиотека распространяется под лицензией Apache 2.0 и доступна через pip, предлагая надёжный и быстрый базис для масштабируемых workloads.

After publishing this a few days ago, 2 things have happened.First, it tuned out that StringZilla scales further to over 900 GigaCUPS around 1000-byte long inputs on Nvidia H100. Moreover, the same performance is obviously accessible on lower-end hardware as the algorithm is not

UUIDv47: приватность v4 + производительность v7

Навигационное меню

Платформа:

• GitHub Copilot
• GitHub Spark
• GitHub Models
• GitHub Advanced Security
• Actions
• Codespaces
• Issues
• Code Review
• Discussions
• Code Search

Ресурсы:

• AI
• DevOps
• Security
• Software Development

Open Source:

• GitHub Sponsors
• The ReadME Project
• Topics
• Trending
• Collections

Enterprise:

• Enterprise platform
• GitHub Advanced Security
• Copilot for business
• Premium Support

Поиск кода, репозиториев, пользователей, проблем, pull requests...

Включите мой email для связи

Отмена Отправить отзыв

Сохраненные поиски для быстрой фильтрации результатов

Имя Запрос

Отмена Создать сохраненный поиск

Войти Зарегистрироваться

• Предложены методы маскирования UUIDv7 для скрытия временных меток при внешнем использовании, сохраняя их внутренние преимущества (сортировка, индексация).
• Обсуждается использование шифрования (Speck, AES) или хеширования (SipHash) для обратимой конвертации между внутренним UUIDv7 и внешним UUIDv4-видным идентификатором.
• Рассмотрены альтернативные подходы: разделение на внутренний и внешний ключ, использование ULID, Sqids (ранее Hashids) или кастомного кодирования.
• Подняты вопросы о практической необходимости скрытия временных меток и рисках (безопасность, корреляция данных для деанонимизации).
• Отмечены проблемы совместимости, сложности реализации и потери некоторых преимуществ UUIDv7 для потребителей API.
• Затронуты технические аспекты: генерация на клиенте, визуальное сравнение UUID, необходимость отдельного поля с временем для клиента.
• Упомянуты связанные проекты и алгоритмы: uuidv47, ULID, Speck, метод из blog.notdot.net.

Kerberoasting — это старая уязвимость в Windows, которая до сих пор работает: злоумышленник, получивший доступ к сети, может перехватить TGS-тикет любого сервиса, зашифрованный паролем учётной записи SPN, и затем в автономном режиме подобрать пароль.

• Не требует привилегий.
• Работает, пока пароль не слишком сложный.
• Microsoft знает, но не считает критичным.

Итог: пароли сервисных учёток — слабое звено; используйте длинные случайные пароли и регулярно меняйте их.

• Kerberoasting всё ещё жив: атака ломает не TGT, а TGS-тикеты, зашифрованные NT-хэшем пароля сервис-аккаунта.
• 99 % проблем — человеческие: админы вешают SPN на обычные учётки, ставят короткие пароли и не отключают слабые RC4.
• Microsoft с 2022 года выдаёт AES по умолчанию, но совместимость оставляет RC4 «для старого», и инструменты вроде PingCastle до сих пор не ругаются на это.
• Пентесты показывают 50 % успеха в 2010-х и всё ещё высокий процент: 21-символьный пароль из менеджера + отключенный RC4 надёжно закрывают атаку.
• Универсального фикса нет: keytab-файлы, строгие SPN, AES-only GPO и ротация паролей работают только вместе, но требуют ручной работы и ломают устаревшие приложения.